Bugzilla – Full Text Bug Listing
| Summary: | Zip import broken | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> |
| Component: | Client | Assignee: | John Arthorne <john.arthorne> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | mamacdon, Szymon.Brandys, tomasz.zarna |
| Version: | unspecified | ||
| Target Milestone: | 0.3 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
This is broken on orionhub and orion.eclipse.org, but works on localhost. Possibly related to build/minification. (In reply to comment #1) > This is broken on orionhub and orion.eclipse.org, but works on localhost. > Possibly related to build/minification. It looks like the file upload does succeed, but the dialog stays open and the UI doesn't refresh which gives the impression that the whole operation failed. What makes this really weird is that I can reproduce the problem on orion.eclipse.org, but not on my local server which is running the same build (same minification, etc). *** Bug 351347 has been marked as a duplicate of this bug. *** It looks like a problem with the widget itself. We do not call any getElementsByTagName("textarea")[0] on our side, so it must be somewhere in the widget code.
(In reply to comment #4) > It looks like a problem with the widget itself. We do not call any > getElementsByTagName("textarea")[0] on our side, so it must be somewhere in the > widget code. This statement is in dojo code (dojo/io/iframe.js). It fails due to a problem parsing the server response during import. On localhost, my server returns: > HTTP/1.1 201 Created > Location: /fileaz > Content-Encoding: gzip > Content-Length: 54 > Server: Jetty(6.1.x) > > <head></head><body><textarea>{}</textarea></body> But on orion.eclipse.org: > HTTP/1.1 201 Created > Date: Mon, 26 Sep 2011 18:25:33 GMT > Server: Jetty(6.1.x) > Location: /fileCx > Content-Encoding: gzip > Content-Length: 54 > Keep-Alive: timeout=15, max=100 > Connection: Keep-Alive > Content-Type: text/plain <----------- > > <head></head><body><textarea>{}</textarea></body> Note the "text/plain" header -- this causes the browser to parse the document as plaintext, so <textarea> becomes <pre><textarea></pre> and everything breaks. Not sure why this is different on my local box (maybe Windows vs. Linux?) John, do you have time to look at this? If not, we should assign to someone so it doesn't get lost... I have pushed a fix. I will verify on orion.eclipse.org tomorrow: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=47b221c3b28c0bea73a96a2a86e009b154bb3dc2 Fixed and regression test added. Verified in I20111003-2200 on orion.eclipse.org. |
0.3 M1 Import from zip is broken. Tested on IE 9, FF6, Chrome 13. Error: HTML Upload Error:h.getElementsByTagName("textarea")[0] is undefined form:this.form,handleAs:"json",error:b...ghContrastImage" alt=""\n/></div>'}); built-table.js (line 779) TypeError: h.getElementsByTagName("textarea")[0] is undefined "xml"){if(b.isIE<9||b.isIE&&b.isQuirks...Next();return a});e.ioArgs._callNext= built-table.js (line 766) TypeError: h.getElementsByTagName("textarea")[0] is undefined "xml"){if(b.isIE<9||b.isIE&&b.isQuirks...Next();return a});e.ioArgs._callNext=