This change (from 3.0.6 to 3.0.7) breaks existing applications using the Icefaces 1.7 inputFile component. File uploads no longer function. See http://jira.icefaces.org/browse/ICE-4144 and http://jira.icefaces.org/browse/ICE-4181
Can you upload a minimized testcase, and/or confirm this is a dupe of bug 484857?
This looks like a duplicate of bug 482659. Please double-check in a build with that bug fixed?
I downloaded firefox-3.0.8.en-US.win32.installer.exe from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.8-candidates/build2/, (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/2009032609 Firefox/3.0.8), and this still fails. That version appears to include the fix for 482659. I think it is not a dupe of 484857, but that's only based on which browsers work and which don't. That is, the 484857 test case fails in Opera & works in Safari, whereas this code works in Opera and fails in Safari. I'll try & find someone who understands the code enough to create a minimized test case, because I sure don't. Summary of my testing: Fails on: Firefox 3.0.7, 3.0.8 (Win/XP/sp2) Safari 4 Public Windows beta (528.16) (Win/XP/sp2) Works on: Firefox 3.0.6 (Win/XP/sp2) Opera 9.64 (Win/XP/sp2) IE6 (Win/XP/sp2) IE7 (Win2003 Server) IE8 (Win2003 Server)
> That version appears to include the fix for 482659. It doesn't sorry. It's just 18.104.22.168 with the two security fixes that caused the firedrill. If you want to test a build with the fix for bug 482659, try the builds in <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0/>. Yes, the versioning looks the same (as of today; will change tomorrow now that we shipped the 3.0.8 firedrill). Which browsers work and which don't in comment 4 is consistent with bug 482659, and the testcase is certainly showing bug 482659. But if you could double-check on the original page with the latest-mozilla1.9.0 build above, that would be great.
> try the builds in > <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0/>. I tested with both the 3.0.8pre (Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:22.214.171.124pre) Gecko/2009032705 GranParadiso/3.0.8pre) and 3.0.9pre (Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:126.96.36.199pre) Gecko/2009040105 GranParadiso/3.0.9pre) from that directory, using the test case, and they work when the page is served via file:, but fail when served from a webserver (http:). (The original app fails, too.) No message in the Error console.
Er, right. I see what's going on here.
Created attachment 370479 [details] [diff] [review] Proposed fix I guess ideally I'd pass the base URI to nsContentDLF too, so it's set in the about:blank URI involved. That needs an API change, which I don't want to do on the branch, but I could add an interface if we think we really want it. There's also a reload issue with wyciwyg here, due to that not preserving the base URI. I think that's a general problem with wyciwyg; I'll file a separate bug on that.
That patch applies on both branches, except for the Makefile.in change (which will need merging). We should probably take it on both, since it fixes a regression from a fix we took on both....
Comment on attachment 370479 [details] [diff] [review] Proposed fix Approved for 188.8.131.52, a=dveditz for release-drivers
Checked into CVS.
Verified for 184.108.40.206 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/2009051305 GranParadiso/3.0.11pre (.NET CLR 3.5.30729. Final file uploading option works now for generated iframe.