Closed Bug 388714 Opened 17 years ago Closed 12 years ago

Reload a page with multiple JS/HTML iFrames and frame contents get swap.

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: moonerent, Unassigned)

References

(
URL
)

Details

(Keywords: qawanted, Whiteboard: SEE COMMENT 66 and 82 on the set of issues in and around this bug. Be sure your test case and comments apply to the right set of issues/bugs.)

Attachments

(13 files, 2 obsolete files)

Test case which reproduces flash issue
181.12 KB, application/force-download
Details
Lighted test with bug (simple test)
100.22 KB, application/octet-stream
Details
Test usage pdf plugin (test_pdf)
28.54 KB, application/octet-stream
Details
Test without FRAME usage
100.02 KB, application/octet-stream
Details
Test without script usage
99.39 KB, application/octet-stream
Details
Some diagrams, displaying rendering sequence
499.71 KB, application/octet-stream
Details
Patch implementation
3.14 KB, patch
bzbarsky
: review-
bzbarsky
: superreview-
Details | Diff | Splinter Review
minimal test case
2.61 KB, application/zip
Details
Testcase with two static HTML pages and some javascript
2.33 KB, application/zip
Details
Testcase results for the attachment #434873
161.23 KB, application/zip
Details
Small Greasemonkey script, to demonstrate the Problem.
2.03 KB, text/javascript
Details
One example that shows the problem
1.63 KB, text/html
Details
Screenshot from Firefox 23.01 showing the issue in Firebug
641.27 KB, image/jpeg
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Screen shot of the bug: http://www.eproof.com/test/firefoxIFrameBug.jpg Reproducible: Sometimes Steps to Reproduce: 1. Simply reload a few times. Actual Results: Content from other iFrames appear in the wrong iFrame. Expected Results: Content generated by an iFrame should appear in it's and only it's iFrame. This bug has been around for the last several versions of Firefox. I marked this bug report as major because iFrames should work. A major ad network will stop considering Firefox as an important browser unless this bug is fixed.
Version: unspecified → 1.5.0.x Branch
Works for me on the trunk - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007071813 Minefield/3.0a7pre ID:2007071813 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007071605 Minefield/3.0a7pre ID:2007071605 The Firefox 1.5 branch is not going to see any more releases. Marking bug works for me since it works in Firefox 2 and the trunk.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
The form was not marked correctly bug is in 1.5 and 2.0 trunks. See screen shot, that proves the bug and it was taken today. Three different people on three different computers in three different parts of the world have confirmed the bug.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Version: 1.5.0.x Branch → 2.0 Branch
I have tried it on two different computers and 6 different profiles the 728x90 ad displays in 2.0.0.5 and trunk for me. try the standard diagnostic to eliminate any profile issues http://kb.mozillazine.org/Standard_diagnostic_-_Firefox
I went to a different computer. Upgraded to 2.0.0.5. Followed the instructions from the Standard Diagnostics. This time it took about 20 reloads, but it happened again. See this screenshot: http://www.eproof.com/test/firefoxIFrameBug2.jpg Try using the back and forward button about every 5 reloads. Thank you all for your attention. The bug is there, it's hard to find, but it's there.
To Rick(bug opener): Where can we find "iframe" in page of the URL you specified? http://www.mercuras.com/steph/adcom_test.htm This sites returns following HTML block for each image part. > (Width)x(Hight)<br> > ****************<br> > <SCRIPT LANGUAGE=JavaScript> > var bnum=new Number(Math.floor(99999999 * Math.random())+1); > document.write('<SCR'+'IPT LANGUAGE="JavaScript" '); > document.write('SRC="http://servedby.advertising.com/.../bnum='+bnum+'/optn=1"></SCR'+'IPT>'); > </SCRIPT><br> > ****************<br> And each script is like next. (SRC of <IMG> tag is determined by URL of above SRC of <SCRIPT> tag) > tagtext="<a href=http://...><img src=http://....gif alt='...'><\/a>"; > document.write(tagtext); And cache is ; - Enabled for main HTML - Disabled for script file - Enabled for image file So mismatch is possibly caused by: (a) Text of "(Width)x(Hight)" in main HTML is not updated when Reload, ("302 not modified" for "Get with If-Modified-Since", ) (or cached version is used because cache is not expired) but <IMG> is updated (b) Wrong image is loaded from cache (bfcahe has relation?) (If this case, probably when "302 not modified" for image)
Script generated <IMG> tag has width/hight attributes. > <img src=http://....gif border=0 width=180 height=150 alt='...'> If case of (b), image is expanded or shrinked to the specified width/height. So I think your screen shot is a result of (a).
Rick, you should try to download one of the trunk builds (what will eventually become Firefox 3; http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/) and try. In comment 1, Kevin suggested that this bug is already fixed there. Note that the Firefox 2.x-version you are using is based on a much older version of Gecko than Firefox 3, which is why you can see bugs that will be fixed once Firefox 3 ships.
I've downloaded the nightly build of FF3 and the bug is still there. Screen shots and code can be found here: http://www.eproof.com/test/ff3.zip The test page remains the same: http://www.mercuras.com/steph/adcom_test.htm I conducted the same tests at the same time in IE7 on the same computer and didn't see this behavior, not even once.
(In reply to comment #8) > Screen shots and code can be found here: "728*90" part(WAL*MART) in simage005.png looks to be image crop by <img height=90>. This screen shot indicates: (1) Text in HTML is "728*90" (2) heght="90" is used in rendering of <img> when Realod (3) But image data used when rendering when Reload has larger height than 90px (Q1) Reload only is used by your test? Or Back/Forward is involved? (Q2) Can you re-produced your problem with newly created profile? a) newly created profile, with Firefox 2.0.0.x b) newly created profile, with Firefox latest-trunk (Q3) When problem occurs, what source is displayed for "View/Selection Source"? 1. Select the image and data around it, by drag operation 2. "View/Selection Source" in context menu Used height/width(real copping size) for script generated <img> is different from View/Selection Source? Or used rendered image data is different from script generated <img src>?
I need time to answer all your fine questions. But allow me to answer those I can now. What makes the task of hunting down the cause of this difficult is the variable of the ad server possibly serving the wrong size ad to the container. This may be the case on occasion, it's been known to happen, however the fact that IE doesn't swap out the ads near the same time would suggest, but not prove, the ad servers (and there's many in this test page) are functioning correctly. Since we don't know exactly what the bug, assuming there is one, is yet then we have to rethink the view source as well. Is it showing what was delivered from the server or was it swapped out from another part of the page? Both points need to be considered, I would think. > (Q1) Reload only is used by your test? Or Back/Forward is involved? In my test, I am only using F5 and the reload button. I've heard rumors that back and forward MAY be involved when caching is involved, but I can't speak to that as I haven't tested it. > (Q2) Can you re-produced your problem with newly created profile? I will try and report my findings. >(Q3) When problem occurs, what source is displayed for "View/Selection Source"? This is a bit difficult because the nesting going on. I think what I'll do is install the Web Developer add-on in the test machine and view "generated source" of both the parent and any iFrames I can get at. Thank you for taking the time to look into this.
Here are my latest test results. Let me know if you need more information. http://www.eproof.com/test/FireFox/200711201624GMT9/index.htm
We are experiencing the same problem on computerbase.de. Very sporadically Firefox shows the wrong contents in an iFrame. This is some kind of race condition and pretty often happens when using the back/forward buttons. To be more specific, the src attribute of the iFrame contains the correct URL. But inspecting the iFrame with Firebug reveals that the _document_ _inside_ this iFrame hasbeen loaded from a different/wrong URL (*) according to its location.href property. Interestingly, you can "fix" this bug by running something like document.getElementById('myiframe').src = document.getElementById('myiframe').src; because, as I mentioned, the src attribute of the iFrame element contains the correct URL. Firefox will happily load the correct document into the iFrame after executing this command. You might think that you could find out which iFrames are affected (by comparing the src attribute of the iframe with the location.href property of the iFrame document) and then apply the mentioned workaround. Bug this approach fails, because usually the iFrame document resides on a different domain and therefore Firefox denies access to its location.href property due to security reasons (you can only read this property by using something like Firebug). (*) The wrong URL is the URL of another iFrame on the same page. I have only experienced this problem when multiple iFrames are used.
(In reply to comment #12) > Firefox shows the wrong contents in an iFrame. To Steffen Weber: As I wrote in comment #5, and as seen in status report(linked) by Rick(the bug opener) in comment #11, test URL of this bug doesn't have FRAME/IFRAME and this bug doesn't have relation to FRAME/IFRAME nor SRC of FRAME/IFRAME, although "frame" is still kept in bug summary. This bug is problem when re-rendering by Reload of <img> which is generated by "script generated <script>", and when "a part of src of script generated <script>" is random, and when "a part of src of script generated <img>" is random. There are at least two bugs which relate to IFRAME and dynamic URL change. Bug 279048, Bug 282198 See these bugs, and open separate bug if new problem, after search bugzilla.mozilla.org well for already reported bugs.
WFM, Firefox 2.0.0.9 and trunk on Linux. Rick, if you can still reproduce this please record the entire network packet exchange using a tool like Ethereal: http://www.ethereal.com/download.html Save it as .pcap file and then put that on a server somewhere and post the URL to it here. Thanks.
I've downloaded and installed ethereal (fyi downloads from their site and their mirrors failed for windows installer because of corrupted files. I found a working copy on download.com.) I also downloaded the just released Firefox 3 Beta 1 and the problem continues. You can download the pcap files here: http://www.eproof.com/test/firefox/FF30B1_Ethereal.zip No new screen shots as they are very similar to the ones above.
Product: Firefox → Core
QA Contact: general → general
Version: 2.0 Branch → Trunk
(In reply to comment #10) > >(Q3) When problem occurs, what source is displayed for "View/Selection Source"? > This is a bit difficult because the nesting going on. Does your real case contain FRAME or IFRAME(and Web page in FRAME/IFRAME is HTML like the test URL)? If so, and if main page doesn't use Flash(Flash intercepts right click), you can see HTML source for <SCRIPT> tag which is generated by <SCRIPT> in HTML, and final <IMG> tag which is generated by <SCRIPT> generated <SCRIPT>, by next operation. (1) Select(reverse) following part in FRAME/IFRAME by drag operation > 728x90<br> > ****************<br> > (image is displayed here, but cropped by height of 90px or smaller width) > ****************<br> > 160x600<br> (2) "View Selection Source" of Context Menu What do you mean by "nesting is going on"? Is Flash used?
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007112805 Minefield/3.0b2pre ID:2007112805 Just tried the testcase with 30-40 reloads and didn't see it. I doubt it got fixed - just seems hard to reproduce. Rick - is there anything you can give us to get a more reproducible testcase? E.g. is it always the same image, after a certain number of reloads, etc...
Keywords: qawanted
Thank you for the efforts. I understand the difficulty of reproducing the problem makes this even harder to fix. I will start thinking of a way where I can create a test page that produces the same error near every time, if it's possible.
Testing Firefox 2.0.0.10 1: Replaced all four ads with direct call to the swf files using SWFObject. Result: Pass 2: Replaced all four ads with direct calls to the swf files using iFrame. Result: Pass 3: Using Firebug I captured the generated DOM. You can see it here: http://www.eproof.com/test/firefox/dom.txt You'll notice on line 287 Javascript creating an iFrame. You'll also noticed in the source URL "160x600". Here it's telling the iFrame to load an ad that size, which is the correct size. On line 298 you the iFrame is created pointing to the correct URL. From lines 299 to 425 you will see the generated code for this iFrame. This body code clearly calls the wrong size ad (728x90). Important to know: -- This code was seen in the correct place in one or more previous reloads. -- This code was not generated by any of the other iFrames etc. -- Because many of these urls are time sensitive, I immediately went to three different computers (one of which still had the mis placed ad in another tab) and loaded the url below literally a hundred times over 30 minute period. Even clearing cookies and cache. NOT ONCE did return the 728x90 ad code. One thing I have noticed, but not proved, is that the vast majority if not all the times the bug shows itself the following factors are true: -- The creative is a swf. -- There's a Javascript include which then, in Javascript, generated an iFrame. -- The swf was seen before in previous page load. http://ad.adlegend.com/iframe?spacedesc=1105976_1063973_160x600_1089384_1105976&target=_blank&@CPSC@=http://servedby.advertising.com/click/site=0000712270/mnum=0000511401/cstr=50677337=_474e924d,3746233440,712270^511401^69^0,1_/bnum=50677337/optn=64?trg= REMOVING ALL OTHER DOMAINS FROM THE TESTING 4: I created a test page that used Javascript to generate iFrames that loaded local swfs. Result: Pass 5: I created a test page that used a JavaScript include that in turn generates iFrames that load local swfs. Result: Reloads caused each of the four ads to randomly display white space. When I inspected the DOM, the correct code was there. A couple of my browsers can see this behavior online: http://www.eproof.com/test/firefox/test.shtml One of my Firefox browsers did not experience the bug it unless I loaded the local files: http://www.eproof.com/test/firefox/test.zip FINALLY we have something close to reproducible. If you look to why this latest test is displaying white space instead of local swfs some of the time, then I am confident you will be able to follow the yellow brick road to the cause then the solution of the swapping of ads. Good luck. Rick
hi, I hope this may help: The problem still persists with 2.0.0.11, even with the nightly build of 3.x from 12-04-2007. I have added a test case files and comment to bug # 315891 (which seemed to be related before I found this one) Tested on XP With the files provided, I am able to reproduce the behavior any time with any single reload. From what I see, it seems like the document put into the iframe is not the one referenced by the src attribute, but the one referenced by the src attribute of the FIRST iframe in the page before it was reloaded etc...
Depends on: 315891
Possibly a dupe of bug 315891. Marking dependent for now...
Hello. I've hired a talented developer by the name of Evgeny, to kill this bug. He's made wonderful progress. Please take a moment to answer his questions. TIA Hello, I'm working at the bug connected with rendering flash banners in iframe. https://bugzilla.mozilla.org/show_bug.cgi?id=388714 Short description: Four JavaScript scripts create four iframes in page with flash file SRC attribute. After some reloads we have white space instead of random flash banner (or banners). I take Rick's last sample. We can definitely repeat this bug. After debugging I found that the problem is in nsPluginStreamListener::OnStartRequest (mDocument- >GetPrimaryShell(),nsplugindocument.cpp:104) method. Sometimes it returns zero pointer for primary shell and I don't know the reason of it. So if pointer returned is zero FF does not pass STATE_TRANSFER while processing event (jump to STATE_STOP) and does not load flash contents. It has random nature (looks like someone delete PresShell object from nsDocument::mPresShells array in unsuitable time). Please explain purpose of PresentationShell and its relations with other objects (frame, document, etc). What do you think is it correct behaviour (absence of primary shell) during reload or something wrong?
Hello, personally, I would not focus on Flash only. As described in https://bugzilla.mozilla.org/show_bug.cgi?id=315891, the problem is deeper and appears with HTML only content of IFRAME. Please take a look there to make sure you are not mislead (although, there might be 2 bugs of course :-) ) thank you very much for your effort
Michal, I almost sure that this bug is not flash plugin bug. The problem is in iframe rendering. To fix it I should understand process of html rendering and purpose of some classes (PresentationShell, etc) more deeply. AFAIK FF divides all document elements into frames(simple rectangles) and begin render since root frame to its children. Do you know how FF present <iframe> in its terms? What the purpose of PrimaryShell in nsDocument? How many PresShells FF create for document (one for each element, one for each document)? Is there any documentation about it( I did't find any except html reflow)? We know effect of this bug (null primary shell), now we should find a cause.
Evgeny, I would really love to help and I highly appreciate that you are working on that. Unfortunately, I am only the problem reporter who is severely suffering from this bug and I don't know anything about FF internals. The only thing I did was that I spent few days trying to find the exact situations when problem appears and repeats. I can offer you help in testing potential solutions, but that is probably all. Sorry for that. I wish you good luck in solving this. Thanks for your efforts!
(In reply to comment #19) > REMOVING ALL OTHER DOMAINS FROM THE TESTING >(snip) > 5: I created a test page that used a JavaScript include that in turn generates > iFrames that load local swfs. > Result: Reloads caused each of the four ads to randomly display white space. > When I inspected the DOM, the correct code was there. >(snip) > One of my Firefox browsers did not experience the bug it unless I loaded the > local files: > http://www.eproof.com/test/firefox/test.zip Phenomenon of "iframe(s) of white space" was observed with Firefox 2.0.6 and Seamonkey 1.1.7 (MS Win-XP SP2), and it occurred even when Shift+Reload. But, I couldn't re-produce the phenomenon with latest-trunk nightly; - Seamonkey latest-trunk : 2007/12/14 build - Firefox latest-trunk : 2007/12/14 build It seems to be timing related issue on current release (reading of local file is very faster than HTTP resource). And the "problem when local file" seems to be resolved when trunk (or window of problem is very very narrowed when trunk). To Rick(bug opener) and Evgeny: (Q1) Can you reproduce the "iframe(s) of white space" when local swf file with latest-trunk nightly build? (Q2) Can you reproduce original problem(script executed in iframe loads image of different size from iframe size) with latest-trunk build? To Evgeny: What do you think about original problem? (A) Simply a script/Flash logic issue when special occasion (B) Something wrong in Firefox causes problem in script (e.g. incorrect iframe size is passed to script or Flash by Firefox) To Rick and Evgeny: Test case with local files consists of following HTML. > <iframe src="728x90_Tomato.swf" marginwidth="0" marginheight="0" hspace="0" > vspace="0" bordercolor="#000000" frameborder="0" height="90" scrolling="no" > width="728"> Because of Flash, and/or because of no room to click in iframe, operation in the iframe such as "Reload of iframe" is impossible. Can you find workaround of this issue in tesing?
(In reply to comment #26) > (Q1) Can you reproduce the "iframe(s) of white space" when local swf file with > latest-trunk nightly build? I've just downloaded latest firefox build and bug is still there. But now it harder to reproduce. Please check files attached (it is a test case which can reproduce bug) > (Q2) Can you reproduce original problem(script executed in iframe loads image > of different size from iframe size) with latest-trunk build? I'll answer a bit later (my internet connection leaves much to be desired) > To Evgeny: > What do you think about original problem? > (A) Simply a script/Flash logic issue when special occasion > (B) Something wrong in Firefox causes problem in script > (e.g. incorrect iframe size is passed to script or Flash by Firefox) I think that second variant is more close. As you can see from my previous post there is no PrimaryShell in nsDocument when we are ready to load flash plugin. But maybe previous reloads have an influence (incorrect working of flash logic as an example)
I've just downloaded and built last trunk. Bug is still there. I'm going to continue my research.
(In reply to comment #29) > I've just downloaded and built last trunk. Bug is still there. I could observe "iframe(s) of white space" too, by attached test case, with Firefox latest-trunk. I seems to have been very lazy(too small try count) when my previous test. I think you'd better to open separate bug for the "iframe(s) of white space" problem, setting dependency of this bug. I believe analysis of "iframe(s) of white space" problem will help analysis of this bug.
After some attempts I found following: Seems that this bug has multi-threading nature. I discovered that while loading flash plugin thread from thread pool is created (child). Then child reads input stream and put nsInputStreamReady event into queue. Main thread get that event and process it. Between this two actions (putting and getting) we have a lot of other events and in my mind there are two most important among them: CSSFrameConstructor::RestyleEvent and PresShell::Reflow. I use VS2005 and output messages about events noted above with help of breakpoints. Interesting moment here: when breakpoints and output are on I cannot represent bug, but when they are off bug is still there. All this resembles race between threads (sometimes we have wrong event's order in queue). Later I'll provide my detailed research of that case. Could you explain (step-by-step) rendering process of last file attached (seems that I miss some important details)?
(In reply to comment #31) > Seems that this bug has multi-threading nature. >(snip) > Could you explain (step-by-step) rendering process of last file attached (seems that I miss some important details)? Combination of NSPR logging & DebugView can produce NSPR log with timestamp, with minimum interference by logging on testing, when MS Windows. See Bug 86396 Comment #7 for NSPR logging with DebugView. (1) Start Firefox with following parameters > SET NSPR_LOG_MODULES=all:5 > SET NSPR_LOG_FILE=WinDebug > CD C:<Program_Library_of_Firefox> > firefox.exe -P (2) Start DebugView with Administrator privilege, and capture required part only, and save data to file. In my test, log size was 50KB to 60KB per a Load(or Shift+Reload), even when NSPR_LOG_MODULES=all:5. So log file can easily be managed. NSPR log may not be useful for detailed analysis of your problem. But it possibly helps further analysis, and timestamp in NSPR log will help analysis when analysis of trace by other tools are also required. I have log produced by above procedure for (a) initial test case load, and no problem, (b) reload, then "white iframe". So if you need log got by me using your test case attached to Comment #28, I can attach the log file.
I can not reproduce bug if I turn on log. I continue think how to cure it ).
I though that nsPluginDocument try to get primary shell before plugin request end its work. So I wrote code in nsPluginStreamListener::OnStartRequest like this: while (!shell && counter < 20) { ::SwitchToThread(); shell = mDocument->GetPrimaryShell(); counter++; } But FF still can't setup primary shell for document. As I've understood data of flash movie is loaded in other thread during processing nsInputStreamReadyEvent. So may be that event is removed from queue due to some condition, or events are placed in incorrect order (FF tries to show movie before processing nsInputStreamReadyEvent). And I can't reproduce that bug if log is on, looks like logging brings delay in work of main thread, so all child threads have time to finish their work.
In this test shows that without FRAMEs bugs doesn't appears.
It shows that no script, no bug.
Now we have some tests, that represent a bug. Tests are attached. One of them, the "simple" one, is the minimum code, that brings the error during the rendering. It is important to make the script as light, as possible - frequency that bug appears depends on the speed of computer (and traffic bandwidth when load online). The second test shows, that this problem does not depend on flash or some kind another pugins. This is a problem of internal mozilla code. To be enshure about nature of bug, there are also test without usage of scrypt and frame. So what is the problem then? When I've been debugging code, I've faced expression of bug. I have breakpoins in two places: - nsDocument::doCreateShell() in nsDociment.cpp, line 2053 - nsPluginStreamListener::onStartRequest() in nsPluginDocument.cpp, line 104 The first one is the place where presentation shell creates and the second one - directly where GetPrimaryShell() calls (and uses created before). So, what can I see? - when bug appears and one or even more plugins are not displayed. I see in ouput that normal sequence [doCreateShell() ... GetPrimaryShell() for each plugin], is broken! In case of bug it calls GetPrimaryShell() first, and it is a cause of error! When I'd delved deeper, I've realised that it may be caused by wrong timer event. This event calls also from queue in nsThread:: ProcessNextEvent(), line 510; and it the result calls GetPrimaryShell() as well...
So, as posted before, there are some interesting place in code: * content\html\document\src\nsPluginDocument.cpp nsPluginStreamListener::OnStartRequest(), line 104. Here calls GetPrimaryShell() - a function, that in error returns zero. * \content\base\src\nsdocument.cpp; nsDocument::doCreateShell(), line 2047. Here creates a new presentation shell for each context. Normally, both this functions calls in right order. But when bug appears doCreateShell() does not calls properly. It calls later and does not do anything useful. For example, normal sequence of call stack looks like: gklayout.dll!nsDocument::doCreateShell() gklayout.dll!nsHTMLDocument::CreateShell() gklayout.dll!DocumentViewerImpl::InitPresentationStuff() gklayout.dll!DocumentViewerImpl::InitInternal() gklayout.dll!DocumentViewerImpl::Init() docshell.dll!nsDocShell::SetupNewViewer() docshell.dll!nsDocShell::Embed() docshell.dll!nsDocShell::CreateContentViewer() docshell.dll!nsDSURIContentListener::DoContent() docshell.dll!nsDocumentOpenInfo::TryContentListener() docshell.dll!nsDocumentOpenInfo::DispatchContent() docshell.dll!nsDocumentOpenInfo::OnStartRequest() necko.dll!nsBaseChannel::OnStartRequest() necko.dll!nsInputStreamPump::OnStateStart() necko.dll!nsInputStreamPump::OnInputStreamReady() xpcom_core.dll!nsInputStreamReadyEvent::Run() xpcom_core.dll!nsThread::ProcessNextEvent()... and then calls gklayout.dll!nsPluginStreamListener::OnStartRequest() docshell.dll!nsDocumentOpenInfo::OnStartRequest() necko.dll!nsBaseChannel::OnStartRequest() necko.dll!nsInputStreamPump::OnStateStart() necko.dll!nsInputStreamPump::OnInputStreamReady() xpcom_core.dll!nsInputStreamReadyEvent::Run() xpcom_core.dll!nsThread::ProcessNextEvent()... But then bug appears, the suquence differ: First, calls gklayout.dll!nsPluginStreamListener::OnStartRequest()... and bug causes… and then, later calls gklayout.dll!nsDocument::doCreateShell() gklayout.dll!nsHTMLDocument::CreateShell() gklayout.dll!DocumentViewerImpl::InitPresentationStuff() gklayout.dll!DocumentViewerImpl::Show() docshell.dll!nsDocShell::SetVisibility() gklayout.dll!nsSubDocumentFrame::ShowDocShell() gklayout.dll!nsSubDocumentFrame::Init() gklayout.dll!nsCSSFrameConstructor::InitAndRestoreFrame() gklayout.dll!nsCSSFrameConstructor::ConstructHTMLFrame() gklayout.dll!nsCSSFrameConstructor::ConstructFrameInternal() gklayout.dll!nsCSSFrameConstructor::ConstructFrame() gklayout.dll!nsCSSFrameConstructor::ContentAppended() gklayout.dll!PresShell::ContentAppended() gklayout.dll!nsNodeUtils::ContentAppended() gklayout.dll!nsContentSink::NotifyAppend() gklayout.dll!SinkContext::FlushTags() gklayout.dll!::WillInterruptParse() gkparser.dll!nsPHTMLContentSink::FlushTags() gklayout.dll!nsContentSink::WillInterruptImpl() gklayout.dll!HTMLContentSink::WillInterrupt() gkparser.dll!CNavDTDarser::ResumeParse() gkparser.dll!nsParser::ContinueInterruptedParsing() gklayout.dll!nsContentSink::ContinueInterruptedParsingIfEnabled() gklayout.dll!nsRunnableMethod<nsContentSink>::Run() xpcom_core.dll!nsThread::ProcessNextEvent()... It seems it creates an empty sub frame and implements it. The real aim of this call needs to be verified. But the real goal is to find a place were the error occurs. The closest to error piece of code placed in docshell\base\nsDocShell.cpp; nsDocShell::SetupNewViewer(), line 6300-6312 Here GetMainWidget(getter_AddRefs(widget)) fails and all other usage object nsCOMPtr<nsIWidget> widget fails also. So next lets go here - nsDocShell::GetParentWidget(), line 3817 - nsDocShell::SetParentWidget(), line 3828 Inside GetMainWidget() calls GetParentWidget() that initialize nsIWidget and fails sometimes. These functions are paired. I have been trying to check if get calls before set, but with breakpoints in both these places bug does not appears (it seems too often output).
Hello. After additional searching I've found that that bug appeared because two events in event queue has incorrect order relative to each other. These events are: nsInputStreamReadyEvent and nsRunnableMethod<nsContentSink> with ContinueInterruptedParsingIfEnabled method. Seems that firefox tries to read stream (flash) data when node parsing is not completed and presentation shell is not created. So I've written raw patch which send InputStreamReady event in the end of event queue if presentation shell was not created before. I'm still not familiar with interfaces which is responsible for working with streams so mozilla developers please provide your feedback. My patches in attachment. Regards, Evgeny
Attachment #328141 - Attachment is obsolete: true
Attachment #328143 - Attachment is obsolete: true
Attachment #328477 - Flags: superreview?(bzbarsky)
Attachment #328477 - Flags: review?(bzbarsky)
Evgeny, thanks for digging into this! So what's happening based on comment 41 is that we get the OnStartRequest from the plug-in data load before we've created a frame for the <iframe>, right? So there is no presentation in the child docshell, and things break (in the sense that the plug-in is not rendered using the nsPluginDocument stuff). This should be simple to reproduce reliably by using a display:none iframe pointing to plug-in data, then waiting for onload and setting removing the "display:none" style, right? Changing the event sequence as this patch does seems like the wrong approach, since there are plenty of reasons the layout object (nsIFrame) for the <iframe> might not have been created yet when OnStartRequest fires. In other words, I don't think the patch fixes all instances of this bug. Evgeny, any idea how the "no presshell" thing actually causes the behavior this bug is filed on (with iframes being "swapped")? Do we do another load when we instantiate the nsObjectFrame for the synthetic <embed> we create and then get different data from the ad server or something?
Status: UNCONFIRMED → NEW
Component: General → Plug-ins
Ever confirmed: true
QA Contact: general → plugins
>> Evgeny, any idea how the "no presshell" thing actually causes the behavior this >> bug is filed on (with iframes being "swapped")? Boris, bug reporters moved to the case when one (or more) flash files are not loaded during reload. Please download this attachement https://bugzilla.mozilla.org/attachment.cgi?id=293273 and try to reload this page few times. Also during my investigation I noticed that replacing flash with pdf files has exactly such behaviour. >> Do we do another load when we instantiate the nsObjectFrame for the >> synthetic <embed> we create and then get different data from the ad server >> or something? I'm not sure I've understood your question right. But in case we cannot get non nullable presshel we simply "forgot" about data request for that frame. Seems the reason is in my https://bugzilla.mozilla.org/show_bug.cgi?id=388714#c42 comment. What do you think?
Hold on. Back up. Are we fixing this bug as filed, or a different bug? If a different bug, there should be a separate bug report for it describing the problem. What is the status of this bug, as filed? Once I have _that_ sorted out we can talk about code changes...
Comment on attachment 328477 [details] [diff] [review] Patch implementation As I said, this doesn't look like the way to fix this bug. Still waiting on an answer to my question.
Attachment #328477 - Flags: superreview?(bzbarsky)
Attachment #328477 - Flags: superreview-
Attachment #328477 - Flags: review?(bzbarsky)
Attachment #328477 - Flags: review-
Boris, I just want to show, that changes in event order tend to results we are trying to achieve. As for your last question: I'm not sure that name and test cases for this bug has a correlation, I'm working with test cases attached. I think that bug reporters can make this situation clear. Rick, if you have time, please explain.
I understand that changing the event ordering can "fix" a timing-dependent bug in some testcases, but that doesn't mean it's a fix for the actual bug. I assume based on comment 51 that in the testcases for this bug you don't see anything swapping? You just see the plug-in not being started?
Yes, some of plugin windows does not start after few reloads. (i.e. we have right-mouse button flash plugin menu, but don't see any content)
Sounds like what would be really useful here is a clean bug with a clean description of the problem to be solved (since we are no longer solving either the problem in this bug's summary or in comment 0). Otherwise it'll be hell for QA to deal with.
Ok, have any thoughs about this timing-dependent bug nature. How can we ensure that events are placed by threads always in right order?
I don't think the order is the real problem. See comment 47.
I just added "<iframe src="#" style="display:none;"></iframe> " under each Adsense, Iframe, or other and the blank frame catches any content misplacements. I call it a BARF BAG! Install your barf bags today!
dweber, Thank you for the clever workaround. I'll have to test it. We've stopped using iframes and JavaScript created iframes on Firefox and Mozilla. The fact that our patch has stalled out at Mozilla suggests to me they agree the iFrame engine is seriously flawed with so many bugs that it needs to be re-written. I hope this issue starts to be taken seriously and a concentrated effort to fix this fundamental feature.
Rick, the patch is going nowhere so far because it's wrong and because I'm still waiting for Evgeny to answer my questions. I'm not quite sure why he just dropped out of contact two months ago. What needs to happen is that someone actually does what I suggest in comment 47, but I'd also still like to understand exactly what that patch (and the issues Evgeny raises, which are very real and need to be fixed) has to do with this bug as filed. I don't think anything here needs to be re-written, much less having "so many bugs".
I should note that looking into the things I raise in comment 47 is on my todo list. It's currently around item 120 or so. It's unfortunate that so many things piled up during the year or so that I wasn't active on Mozilla, but there we are.
Boris, Thank you for your prompt responses. The iFrame issues are great than this ticket. Evgeny was discouraged by the response to his patch. He went out of his way to learn as much as he could about code that this would impact, but was direct and pleaded for help from those who know more. No help was to be had. If you want to understand how wide spread this iFrame issue is I would be happy to schedule an phone conversation so I give you a brain dump. After our call I think you'll come to understand there's a serious flaw. Rick
Rick, I just asked Evgeny for the information he might have had from when he was clearly debugging this; if he didn't actually have it, he should just say so. I'm not expecting miraculous production of data out of nothing here... I also tried to point him in the direction of the code that really should be fixed here; he didn't seem to be interested. I understand that people are running into this; that said, the relatively small number of reports makes it sound like this isn't something users hit every single day. That doesn't mean that it's not a problem, or that it shouldn't be fixed, nor does it say anything about the state of the code. In any case, if someone is willing to dig into the stuff from comment 47 I would be happy to hand-hold as much as needed. Locating me on the #developers channel on irc.mozilla.org during work time EDT is probably the easiest low-latency communication method.
(In reply to comment #62) > I understand that people are running into this; that said, the relatively small > number of reports makes it sound like this isn't something users hit every > single day. Boris, sorry to say that but I think this is wrong. Not having many reports doesn't mean that people don't run into this. First, not everyone is capable/willing to spend time sending reports (especially if doing so does not have any effect on solving it like here) Second, there are many iframe issues arround, many of them seem to be related, so you should sum the up. Third, although it affects almost every internet user (ads are often served through iframes) - those users are in no way motivated to report this. It is ad serving solution providers or advertisers who are at the end affected and there's much less of them who would report. Finally, (I have already mentioned that), as nothing happend (except for the hope provided by Evgeny - thank you!) on this issue for a year, most of us had to use some workaround. Either completely abandon iframes, or abandon them in Mozzila with ugly browser sniffing. And abandoning iframes is bad... there were legitimate reasons for using them (like not affecting the rendering of the publishers page when serving the ads from the third party system) Being in the software development business, I understand there are many things to do and that things need prioritization. I just think this issue is being treated as unimportant while it actually affects almost every internet user (at least their web experience - it is not nice to see 120x600 banner displayed in 468x60 position). I hope you admit that advertising is present almost everywhere and it is hard to avoid it.
Michal's comments are right on point. Thank you for speaking up. Boris, thank you for the IRC info, it's typing I try to avoid, so I will go ahead with sharing my most recent Mozilla iFrame struggles. I spent 15 hours last Wednesday so it's fresh in my mind. The below is technically off-topic for this ticket, however I won't be opening tickets for the following... ---- A quick search of Bugzilla with the search term iFrame returned 200 results, for whatever that's worth. ---- My client publisher's home page generates 25 million page views (not hits) per day. Each day averages 1.6 million unique visitors (by ID). Mozilla browser constitute 30% of the traffic. On this home page there are four ad containers (banner, left, right, tower) which are generated by our domain, not the publishers (this may play a part in one of the bugs.) Banner is a nested JavaScript include that generates html. Left, Right, Tower are JavaScript includes that that use document.write to create a iFrame. I found that if I construct the iFrame src with JavaScript ('... src='+myURL+'...') that across all browsers there's a JS bug when visitors reload the page or return to the page using the back button, the src is called twice with the first call being aborted about 85% of the time. The work around for this bug worked in all non-Mozilla browsers: myFunction return ''; src="javascript:myFunction()" frames[frameName].location = 'http://mydomain'; What did Firefox do with this workaround? It called the source two times, neither time aborted. How can it with the first src being '' you may ask? Amazingly it reloads the last url in any iframe with the same domain. I was not pleased to discover that FireFox (I apologize for using FF and Mozilla interchangeably) does not check first that the src is a proper url before deciding to make the call. Before moving on, let's review. High trafficked home page has: Banner: nested JavaScript includes generating HTML. Left, Right, Tower for non-Mozilla browsers: JavaScript include that document.writes iframe src="javascript:myFunction()" Left, Right, Tower for Mozilla browsers: JavaScript include that document.writes iframe src="'+myURL+'" The ad impressions for these ad containers should be distributed like so because of table layout and visitors clicking away from the site before the ads are called: Banner: most impressions Left: second most Right: third most Tower: fourth most However, with the aforementioned code setup we get, because of Mozilla browser (I have detailed and real time logs that verified this, details of which are too much to include in this post.) Banner: second Left: least Right: third Tower: most, in fact it had 15% more impressions than the PAGE impressions. [snip hours of wasted time looking for a workaround, just like the bad old days of IE6, sorry but it had to be said.] Finding no solution I decided to make all the Banner, Left, Right and Tower nested JavaScript includes returning HTML for only Mozilla browsers. Ah but it doesn't end there, with a little luck I found yet another NASTY Firefox iFrame bug... So I changed all four ad containers to nested JavaScript for Mozilla on the server. I hit reload and I see the iFrame ads!!! Did I make a mistake on the server, was the iFrame code cached? Hmm, let me check with HTTPWatch (yes they now have a version for FF, nice. I know about the FF addon, while I give a thumbs up to that developer I had already purchased HTTPWatch) and sure enough enough there is NO IFRAME CODE BEING RETURNED. Nested Javascript to HTML are being returned, and I know this because they return different ads, in fact the JS iframes didn't return an ad they were hard coded to google.com while I was testing. Let me repeat, I hit fresh and I see google.com in iframes, yet not a single line of code contained an iFrame. I had to do a hard cache purge in Firefox before it stopped. Don't be confused, the files where NOT cached, non iframe code was returned by the server. Proof it wasn't just me... after I put the Mozilla only nested JS into production the impression distribution started to return to normal very slowly. It's taken four days and finally all the Mozilla browser have cleared their special iframe (not file) cache, and the numbers have returned to normal. As incredible as this story sounds, it's true. It doesn't matter to Firefox users because now they have to wait to all the ads deliver before they can see the publishers content at best and at worse third parties have access to publishers sites. Now do you understand why I suggested a phone call :-) I truly hope this helps. Rick
Thanks Rick, I'm happy to help in any way while this gets worked out. (I found that trick elsewhere and just polished for myself) Unfortunately, the newest version of Safari (Mac and Windows) has a problem understanding the "Do not display" command and ends up displaying my "Barf Bags" As only single digit% of traffic uses Safari, my boss is alright leaving things for a while. Please let me know if you find anything else out. I just love using such a simple line of code here and there instead of completely rewriting my pages while Firefox gets sorted. Best wishes to all Dweber (In reply to comment #58) > dweber, > Thank you for the clever workaround. I'll have to test it. We've stopped using > iframes and JavaScript created iframes on Firefox and Mozilla. The fact that > our patch has stalled out at Mozilla suggests to me they agree the iFrame > engine is seriously flawed with so many bugs that it needs to be re-written. I > hope this issue starts to be taken seriously and a concentrated effort to fix > this fundamental feature.
Michal, don't get me wrong. Few reports doesn't mean it's not a problem, just that _users_ typically don't notice it or that their internet browsing is not seriously affected by it when they do. Which means it's a lower priority than security bugs or crashes that affect users directly and noticeably. It's clearly a high priority for you, and I appreciate that. Rick, the 200 results is worth basically nothing (though for what it's worth, I agree that there are a number of issues with iframes in general, especially because there are self-contradictory behavior requirements for them). For one thing, a lot of those 200 bugs have to do with nsIFrame (the Gecko class representing a CSS box), not with HTML <iframe> tags. For another, just for comparison, there are 3995 bugs that come up for a similar search on "table", and I don't see anyone claiming that tables are so broken that they need a rewrite. > The below is technically off-topic for this ticket True, and it makes it harder to fix this bug, by cluttering it with irrelevant information, which makes it hard to find the parts that ARE relevant. For what it's worth, at least the first issue you describe is already filed, and is by-design at the moment. A phone call to discuss what? We agree that this bug needs fixing. I could use some information from Evgeny or you to expedite that, and a phone call is not an efficient way to communicate that: commenting in the bug, e-mail, or any other medium that leaves a copy/pastable written record is much better. If that information is not forthcoming, that will just make this bug all the harder to fix; see below. I do apologize for the long time it took for someone who knows something about our iframe code to look at the bug, and for the long string of more or less irrelevant comments way at the beginning there. Not much we can do now to change that, but moving forward it would be good to get this fixed as quickly as possible. So again, to summarize the current state of things here as I understand it: 1) There is a bug where reloading a page with multiple iframes all pointing to flash files sometimes swaps their content. This is reported in comment 0. 2) There is a bug where reloading a page with multiple iframes all pointing to flash files sometimes shows one of the iframes as blank. This is reported in comment 22. This comment also describes why the iframe is blank. 3) I don't see how the second bug could lead to the first one, as I said in comment 47 and comment 49. 4) The URL in the URL field of this bug doesn't have any iframes in it. 5) The attachments attached to this bug report cover the second bug (blank iframes) not the first bug. I have filed bug 458100 and cced Rick and Evgeny on it to cover this second bug with blank iframes. Thanks to Evgeny's work the problem there is well-understood, and easy to reproduce. What I'm still not clear on is the state of the bug this bug report was originally filed for. Is it still a problem? If so, is it just plugin-specific or really iframe-specific? The original URL the bug is reported against doesn't have any iframes, so a page that shows the original bug, if still relevant, would be much appreciated.
(In reply to comment #66) > Michal, don't get me wrong. Few reports doesn't mean it's not a problem, just > that _users_ typically don't notice it or that their internet browsing is not > seriously affected by it when they do. I agree. Typically, users are not SERIOUSLY affected by misplaced iframe content if it's advertising but still, the browsing experience IS affected and this problem MAY also affect internet applications. We, in our company, come across this problem again and again and because we know about it we use workarounds (for the most recent project for example, we are forced to issue reload on iframe before we show it to the user for example). Probably many do use this or other workaround and don't bother to report...or are forced to abandon IFRAMEs in FF. > So again, to summarize the current state of things here as I understand it: > 1) There is a bug where reloading a page with multiple iframes all pointing to > flash files sometimes swaps their content. This is reported in comment 0. disagree here. The problem is NOT linked to flash. Content gets swapped even for a basic HTML. See my original report in https://bugzilla.mozilla.org/show_bug.cgi?id=315891 (comment 20 in this bug). And, it IS very probably a timing issue as with Firebug enabled, it never occurs. I am sorry I can't help more than giving you all the info I have. I spent days chasing the bug down to be in Mozilla, not in our code. And I hate saying our customers that we can't do anything about the problems they face on their websites except for they can stop using iframes :-( So, I really appreciate the time you invest into this and I hope it will lead to the solution....
Michal, your bug doesn't sound like it's the same as the bug originally reported here. I've marked yours as duplicate of the relevant bug.
I checked in the fix for bug 458100. Rick, would you or Evgeny be willing to retest with tomorrow's nightly builds, and let me know what things look like on your end?
Hello, Sorry I was a bit busy and can't participate in your discussion, but I'll look into nighty build.
adding myself to the bug as I work for a business that supplies ads via iframe on to various publisher sites and I do sometimes see this problem. In our case the iframe contents are HTML. I'm using Firefox 3.0.3. If there's something I can do to help, please let me know.
We are seeing this too in one of our facebook apps, the iframes do not match when you navigate using the back button.
If you can create a smallish testcase (or heck, any testcase) that reliably shows the problem, I suggest filing a new bug on it and ccing me.
Here is a simply reproducible test case version probably related to this bug. https://bugzilla.mozilla.org/show_bug.cgi?id=464064
Attached file minimal test case —
I've attached a minimal test case - The javascript randomly inserts either an iframe with a pink border w/ src=pink.html or an iframe with a green border w/ src=green.html. If pink iframe shown on first page load, any refresh where the green border is shown will use the pink.html content. If green-bordered iframe is first, it shows green.html content on page loads with pink iframe.
(In reply to comment #76) > Comment 75 sounds like bug 279048. I don't know the details of the code involved with this, but I am a developer at a small web company (MyRockstar.com) that is keenly interested in seeing this problem fixed. My gut feeling is that bug 279048 is more of a procedural issue, whereas this bug is race condition.
> My gut feeling is that bug 279048 is more of a procedural issue, whereas this > bug is race condition. Oops, sorry, I take it back. Our Director of Production is telling me that it does have to do with reloads, so bug 279048 may very well be related.
note: per feedback on the intercommunity meeting from the spanish team, this affect one of the 2nd largest news site in spain. So requesting blocking 1.9.2 and wanted 1.9.1 to get this on the radar
Flags: wanted1.9.1?
Flags: blocking1.9.2?
The solution adopted by the news site about the comment #79 from Tomcat is the one displayed below, although sometimes it does not work. It is a terrible patch that we hope will be soon solved ;-) var checkIframes =function() { for (i=0; i<window.frames.length; i++) { try { if (window.frames[i].document.location.href != window.frames[i].frameElement.src && !(window.frames[i].document.location.href == document.location.href && window.frames[i].frameElement.src == 'about:blank')) { window.frames[i].frameElement.src = window.frames[i].frameElement.src; } } catch(e) {} } }; var userAgent = navigator.userAgent.toLowerCase(); if (userAgent){ var browserFirefox = /mozilla/.test( userAgent ) && !/(compatible|webkit)/.test( userAgent ); if (browserFirefox) { $(document).ready(checkIframes); } }
Flags: blocking1.9.2? → blocking1.9.2-
Flags: wanted1.9.2?
Here's an example of a case that fails quite frequently http://www.dianomioffers.co.uk/partner/babynames/demo2.epl If you reload just a few times you should see the 'This content gets replaced' iframe getting replaced, or replacing the other iframes. I'd be happy to try to produce a minimal test case - if there's anyone who might actually work on a fix? We run iframes on lots of UK publisher sites and see this frequently.
its not clear that much progress has been made in getting the things that boris identified in comment 66 almost a year ago. it sounds like we still need good minimal test cases in the right set set of bugs to make better progress on the issues that remain, and this bug needs a good mimimal test case for comment 0 and comment 66. I've been trying to get the test case in comment 81 to work for me, but no success in reproducing a bug using Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090912 Shiretoko/3.5.4pre once we get that test case working for a few people we can figure out which bug it might be connencted to. I do see the image sizing problems with several reloads of http://www.mercuras.com/steph/adcom_test.htm as posted in comment 8 and I do see the problem of color mismatches in the test case posted in comment 75 in which I have hosted at http://people.mozilla.com/~chofmann/bugs/388714/test/ maybe its time to close this bug, open a tracking bug titled "it's not nice to see 120x600 banner displayed in 468x60 position" then link in bugs that could lead to this condition. these bugs sound like candidates for the kind of problem that ad publishers seem to be encountering and should be fitted in under the general tracking bug. Bug 279048 - dynamically created iframe in a static page doesn't refresh source url on reload and its dup - Bug 315891 - nested frames/iframes with dynamically changing url do not show correct document ---should the test case in commment 75 be moved over to bug 279048 ? Bug 282198 - If SRC URL of IFRAME is static but the URL is redirected to other URL by "302 Found", HTTP GET when "Reload" is issued to the last redirected URL instead of URL on IFRAME then we might need new bugs and a fresh start for comment 47 and the investigations boris has plans for there. possible title OnStartRequest from a plug-in before we've created a frame causes plug-in's to not be rendered. and any other bugs that we can get articulated.
Whiteboard: SEE COMMENT 66 and 82 on the set of issues in and around this bug. Be sure your test case and comments apply to the right set of issues/bugs.
> comment 47 and the investigations boris has plans for there. Do you men the last paragraph? The first paragraph is covered by bug 458100, which is fixed. I'll make sure the regression test for that gets checked in, now that we have a test plugin.
* it's _not_ working with local files, you have to put on a webserver to work with * do _not_ wait for page to fully reload (double hitting reload button without waiting shows the bug)
The attachment shows the testcase results with the correct and the incorrect rendering.
If you are generating iframes from JS this happens to be a problem. Just by luck I found out, instead of setting 'src' attribute of iframe before appending it to body, set 'src' after appending to body like: // THIS DOES NOT WORK, MIXES UP FRAMES var frame = document.createElement('iframe'); frame.setAttribute('src', frameSrc); document.body.appendChild(frame); // THIS WORKS var frame = document.createElement('iframe'); document.body.appendChild(frame); frame.setAttribute('src', frameSrc);
(In reply to comment #86) > Just by luck I found out, instead of setting 'src' attribute of iframe before > appending it to body, set 'src' after appending to body like: Nope. Doesn’t work here. By the way: WhyTF is this not fixed? I know this bug since 1.0! If any developer who’s responsible hears this: What can I do to get this fixed in the next days? Whatever it takes. Just tell me. By the way: Here, this bug just does the following: You set the src of the iframe, then try to access the document inside, and it’s empty or the wrong one. Meaning: Switch from non-blocking to blocking, and you’re done. :) Or at least make non-blocking possible. Should be so easy, a intern can do it. Non-blocking is harder than blocking, since blocking is the default when one writes code, since multi-threading takes more work.
Navid Zamani, are you seeing this issue in a current Firefox 4 beta?
(In reply to comment #88) Yes, I just installed it, and tested my script. Same thing.
Can you link to a testcase, or attach one to this bug, please?
Here’s one. Just load it into Greasemonkey, and refresh this page. (Don’t forget to disable it afterwards. :)
I don't get it. That script inserts an iframe with an src, and then immediately (before the src has even had a chance to start loading) pokes at the contentDocument DOM. Of course it doesn't find the src content at that point: it hasn't loaded yet! Am I just missing something?
(In reply to comment #92) Uum, why in the world would the src assignment statement need or take any asynchronous time? It’s not like it has to fetch some external document. As I said above: meaning: Switch from non-blocking to blocking, and you’re done. :) Or at least make non-blocking possible. Also, try my script on any page with as many other iframes as possible, and there will be iframe mixups.
All loads are always async. Period. That includes data: loads. It just so happens that changing that would break the web, by the way.
What would iframe mixups with that script look like?
isn't my testcase good enough to reproduce the problem? #c84
Do you see the problem with that testcase on trunk? I don't so far...
(In reply to comment #94) > All loads are always async. Period. That includes data: loads. It just so > happens that changing that would break the web, by the way. I can not argue with that deep and intelligent reasoning. The arguments just are too good. And why would one think about decisions made that long ago anyway? If people stopped thinking about them, and forgot the reason for them, then clearly there’s no point in ever re-thinking them again, and we should just believe in them until the end of all times! Because things never change and also *should* never change. Even if that means that if you want to do “loads” in Greasemonkey and similar systems, you can not keep function-scoped variables over the wait of setTimeout, because the usual way of setting them as properties of globals (like window) does not work. Who needs “loads” anyway, right? Now excuse me, I have to light my perfectly good oil lamps on my horse car, or I might not make it through the night.
(In reply to comment #95) > What would iframe mixups with that script look like? The content of any iframe being loadad into another random iframe, instead of the one it was supposed to go in. I tested it with a page with 3 iframes, showing me an alert of the title of the page that was loaded into my iframe (as identified trough a long unique id). And every couple of refreshs, it showed me the title of another iframe from that site.
(In reply to comment #97) > Do you see the problem with that testcase on trunk? I don't so far... I’m not a Mozilla developer, so I won’t figure out how to fetch and build from trunk, and not wreck my work environment. But it’s nice to hear the problem being probably fixed. But make sure you have many iframes, some being loaded by JavaScript. I recommend a site using lots of ads in iframes, no ad blocker, and a Greasemonkey script to add your iframe.
This bug is still valid - though in my opinion it's extremely hard to reproduce reliably. It usually happens with generated iframes, where javascript generates a script tag (with document write for example), the script tag fetches a javascript file and the javascript file finally document writes an iframe with an src; unfortunately that's how most ad servers work. I can make a video to prove it, but I had been struggling for hours to produce a *reliable* test suite; but if we manage to make one, I'll post it here. Until then, here's a way to reproduce it (it happens in Firefox *only*; I tested it on Win7): 1. go to http://www.ustream.tv/ 2. switch to Japanese (in the footer) 3. wait for page reload; in the topmost "recommended live" box choose a popular channel; I choose this one for example: http://www.ustream.tv/channel/tanisan-aksktv 4. on that channel page scroll down to the footer, change the language back to English (this is a form GET and a redirect actually: page -> page?lang=en_US -> store lang in cookie/session -> reload to page) 5. some of the iframes might be mixed up already 6. if not, change the language again, until it happens (it happens after two or three attempts for all of us; returns to normal after a couple of page reloads) 7. if it happens, examine the page source and then the generated code (use firebug to check the iframe src attributes): the contents are all mixed up, while the src attributes are still okay. Sometimes an ad lands in the Social Stream, sometimes a hidden facebook iframe lands in an an ad box... Hope it helps - I know that this is a very old bug and it is very hard to reproduce, but we're sure it's still around.
ps.: this never seems to happen with Firefox beta 11 - Firefox 3.6.13 is effected though.
Yes, in Firefox 4 there was a significant session history rewrite to deal with cases like this. Hence my questions in this bug about whether people can reproduce the problem in Firefox 4. There's no point testing in Firefox 3.6.x.
I can confirm this is still happening in Firefox 4.0.
Mike, on what testcase?
I created a simple one in comment #84
See comment 97. I can't reproduce any problems on that testcase....
I can confirm this is happening with 4.0.1 I can reproduce it with multiple reloads with a web page that has 10-12 iframes in which some additional small images are also loaded from the web server. Sometimes the page has the same iframe 2 times even though the iframes are all using different URLs to load. I found out, that in the web server access.log some of the iframes are requested two times and some are not requested at all. It seems, that Firefox mixes up the requests and asks for the same iframe multiple times while leaving out others. Here is an extract of the web server access.log (obscured) 1.1.1.1 ... "GET /getIframe1 HTTP/1.1" 200 2313 "-" "Mozilla/5.0 (Windows... 1.1.1.1 ... "GET /getIframe2 HTTP/1.1" 200 2149 "-" "Mozilla/5.0 (Windows NT 5... 1.1.1.1 ... "GET /getIframe3 HTTP/1.1" 200 2366 "-" "Mozilla/5.0 (Windows... 1.1.1.1 ... "GET /getIframe4 HTTP/1.1" 200 2388 "-" "Mozilla/5.0 (Windows NT 5.1 1.1.1.1 ... "GET /getIframe5 HTTP/1.1" 200 2189 "-" "Mozilla/5.0 (Windows NT 5.1 1.1.1.1 ... "GET /getIframe6 HTTP/1.1" 200 2244 "-" "Mozilla/5.0 (Windows NT 5 1.1.1.1 ... "GET /getIframe7 HTTP/1.1" 200 2721 "-" "Mozilla/5.0 (Windows NT 5 1.1.1.1 ... "GET /getIframe8 HTTP/1.1" 200 2375 "-" "Mozilla/5.0 (Windows NT 5 1.1.1.1 ... "GET /getIframe9 HTTP/1.1" 200 1950 "-" "Mozilla/5.0 (Windows NT 5 1.1.1.1 ... "GET /pic1.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /pic2.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /pic3.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /pic4.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /pic5.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /getIframe7 HTTP/1.1" 200 2721 "-" "Mozilla/5.0 (Windows NT 5... 1.1.1.1 ... "GET /pic6.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /pic7.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /pic8.gif HTTP/1.1" 304 - ... 1.1.1.1 ... "GET /pic9.gif HTTP/1.1" 304 - ... As you can see, the 10th iframe is not even requested, instead the 7th requested twice.
We are looking for a minimal testcase that boris or one of the other developers can use to reproduce the issue.
You need 10-12 iframes onto a web page that loads different contents each, from the same web server. When doing refresh fast a few times, sometimes there are iframes with the same content which should not happen.
Attachment #539142 - Attachment mime type: text/plain → text/html
BoBo, thank you for the testcase! I haven't been able to reproduce the problem with it so far, unfortunately.... :(
This might be OS related. I can reproduce it in WinXP 32bit easily (do not even need to smash F5 for refreses too many times) as well as in Win7 64 bit (much harder, it is rare /much faster computer/), but not in Ubuntu 10.10 (VMWare VM)
No it's unrelated. They just have bad cache expiry headers. I commented on the article.
Not able to reproduce on Latest Nightly 21.0a1 on Windows 7 x64 and Mac OS 10.8 following testcases attached. Based on this and on Comment 111 I consider this issue Resolved WFM. If anyone can still reproduce this issue on latest builds please reopen it.
Status: NEW → RESOLVED
Closed: 17 years ago → 12 years ago
Resolution: --- → WORKSFORME
Attached a screenshot showing the behavior still in Firefox 23.01 on Windows 7 64-bit. Actual content of the iframe doesn't match src. The content in the iframe should be in another iframe way further down on the page. The source of the actual content in the iframe is http://static.vg.no/pengerno/vg_390x210.html. Both iframes are inserted dynamically with document.createElement('iframe') and appending it. Src attribute is set before appending the iframe to the document. The issue occurs in several cases (first load, reload and back), but the most reproducible (but still extremely erratic) is when going back. We've managed to make a logging service when it occurs which is at least once every 10 minutes and are thus able to see effect of any workarounds almost instantly.
Can you reduce this to a test-case or provide an URL that doesn't change so it can be tested?
I've tried, but unable to make something which consistently reproduces it. Rough estimation is that it happens in about 1 per 100.000 pageviews in our production environment. What I've done is setting up a small test which reloads the page several times, and trying to see if the content is correct (bit hard as the DOM is confused). I'm open to suggestions on how to provide better data on this issue.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: