Closed Bug 481647 Opened 15 years ago Closed 15 years ago

[FIX]Internal frame with generated src by javascript is not working properly in FF 3.0.7, used to work in FF 3.0.6

Categories

(Core :: DOM: Navigation, defect, P2)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1

People

(Reporter: dragan.spirov, Assigned: bzbarsky)

References

Details

(Keywords: fixed1.9.1, regression, verified1.9.0.11)

Attachments

(2 files)

Test case, shows iframe cases that work & don't work
2.12 KB, application/zip
Details
Proposed fix
7.84 KB, patch
jst
: review+
jst
: superreview+
dveditz
: approval1.9.0.11+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.7

Inline frames that have scr generated by javascipt, for example <iframe src="javascript: document.write('<html>.....');document.close();"></iframe> are not working properly. Inline frame will be displayed, but form inside this internal frame that contains input[type='file'] will not be submitted when clicking on submit button.

Reproducible: Always

Steps to Reproduce:
1.Create page containing  <iframe src="javascript:document.write('<<FRAME_CONTENT>>')"></iframe>. Inline frame should contain form that will upload file to the server and submit button.
2.Click on submit button
3.
Actual Results:  
Submit button does nothing, nothing is logged, no event

Expected Results:  
Form should be submitted
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?
Keywords: regression, testcase-wanted
Whiteboard: [same as bug 484857?]
This looks like a duplicate of bug 482659.  Please double-check in a build with that bug fixed?
Keywords: regression, testcase-wanted
Whiteboard: [same as bug 484857?]
Keywords: regression, testcase-wanted
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:1.9.0.8) 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)
Ok, I got a test case from http://jira.icefaces.org/browse/ICE-4144, and cleaned it up a bit.  It actually shows 2 iframe cases that work, and one that doesn't.

The failing case is different because the iframe src is generated by javascript. In all 3 cases the action= value is a relative URL.  If you change the failing case to have an action with a fully qualified URL, then it works.

This test is quite a bit simpler than bug 484857 -- it requires only a single html page (plus the target of the action=, to see if the action is taken).

BTW, regarding the Opera response, I found there's a twist -- the test case works if served by a webserver, but fails if you open the page from disk.  In the failing case the error console says "Network - file://localhost/C:/TEMP/bugtest/uploadComplete.html   The loading of the URL has been blocked for security reasons."  AND it fails even if you fully qualify the action URL in the javascript.

The Firefox error console (in 3.0.7+) does not show any messages.
> That version appears to include the fix for 482659.

It doesn't sorry.  It's just 1.9.0.7 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:1.9.0.8pre) Gecko/2009032705 GranParadiso/3.0.8pre) and 3.0.9pre (Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.9pre) 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.
Assignee: nobody → bzbarsky
Blocks: 445004
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: testcase-wanted
Component: General → Document Navigation
Product: Firefox → Core
QA Contact: general → docshell
Attached patch Proposed fix — — Splinter Review 
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.
Attachment #370479 - Flags: superreview?(jst)
Attachment #370479 - Flags: review?(jst)
Summary: Internal frame with generated src by javascript is not working properly in FF 3.0.7, used to work in FF 3.0.6 → [FIX]Internal frame with generated src by javascript is not working properly in FF 3.0.7, used to work in FF 3.0.6
Attachment #370479 - Flags: superreview?(jst)
Attachment #370479 - Flags: superreview+
Attachment #370479 - Flags: review?(jst)
Attachment #370479 - Flags: review+
Flags: blocking1.9.1?
Flags: blocking1.9.0.10?
Pushed http://hg.mozilla.org/mozilla-central/rev/6e255383fe1e
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
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....
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.10?
Flags: blocking1.9.0.10+
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1
Comment on attachment 370479 [details] [diff] [review]
Proposed fix

Approved for 1.9.0.10, a=dveditz for release-drivers
Attachment #370479 - Flags: approval1.9.0.10+
Checked into CVS.
Keywords: fixed1.9.0.10
Verified for 1.9.0.11 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11pre) Gecko/2009051305 GranParadiso/3.0.11pre (.NET CLR 3.5.30729. Final file uploading option works now for generated iframe.
Keywords: fixed1.9.0.11 → verified1.9.0.11
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: