If I do an out of band document.write() and omit the document.close() call, the throbber never stops. We need to fix this behavior so that the throbber stops.
If a script doesn't call document.close(), how can the browser you know when it's "done" writing to the document, and it's safe to stop the throbber and fire onload?
There is the same problem when necko requests a document and the server does not say how long the document it, and the server does not say when the document ended. Probably in all these situations the answer is: we do not know for sure when to fire "load" and think the load finished. But we can, and we must, do something about situations like this. There are probaly several ways to do that. One method is a timeout. If we do not receive new data in a certain timeframe (and it is arguable what would be a safe/sensible timeout), we assume the load finished and do the appropriate thing.
Setting target milestone to 0.9.2
Target Milestone: --- → mozilla0.9.2
I use the search links bookmarklet <http://www.squarefree.com/bookmarklets/pagelinks.html> on long pages, and sometimes there's a long delay between document.writes() as the script searches through the page. The script doesn't rely on onload, so as long as it can continue write()ing to the document after a pause, it won't break. It would be neat if the throbber could continue throbbing until the search is complete, though.
Moving P2 and P3 bugs over to 0.9.3...
Target Milestone: mozilla0.9.2 → mozilla0.9.3
See also bug 77989, documents created using (a) doc.write without doc.close or (b) data:text/html wait 1.2 seconds before painting.
Not platform specific bug
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 91625 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Bulk re-assign of my 0.9.4 bugs to Heikki. I will not have the cycles to work on these bugs while Clayton is on sabbatical for the next six weeks.
Assignee: nisheeth → heikki
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Interesting... here are my results from comparing the three tests between IE6 and NS 6.1 (the throbber always stays on in Mozilla and always goes off in IE6): test NS6.1/Mozilla IE6 1 no load event no load event 2 2 load events, you get 2 alerts, both docs quickly loaded but second doc will not be loaded until alert dismissed 3 no load event, no load event, immediate display 1-2 sec delay in display Additionally, in IE6, if you reload the page after you have run your test, you will get all the events. It looks like IE6 is actually reloading the JS generated page, not your original source. Mozilla reloads the original source. I do not know which is correct behavior, jst/radha/anyone? The bottom line, on first load IE6 and Mozilla behave the same in regard to the load event. On reload IE6 fires all the events you'd expect it to fire (if you know it will reload the generated content and not the original doc).
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.8
*** Bug 108687 has been marked as a duplicate of this bug. ***
Why does Mozilla have to create a behavior that is different than any other browser? No other browser animates the throbber on a document.writeln. Heck, I would bet that most people don't even know about document.close. They do document.writeln and it works. Why do we want to create more situations where Mozilla is perceived as "broke" especially in an area where the spec does not dictate how it should behave?
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Major corporations depend on eapp bugs, and need them to be fixed before they can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to nominate.
Keywords: nsbeta1+ → nsbeta1
*** Bug 100638 has been marked as a duplicate of this bug. ***
No easy solution in sight, no major user impact that I know of. Futuring and minusing.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → Future
*** Bug 77989 has been marked as a duplicate of this bug. ***
As the 77989 has been made a duplicate I make the summary a little bit broader.
Summary: doc.open()/doc.write() without doc.close() does not stop throbber → doc.open()/doc.write() without doc.close() does not stop throbber and trigger repaint
*** Bug 143019 has been marked as a duplicate of this bug. ***
Looks like we have missed the train for 1.0.1. Can we retarget this for 1.2?
*** Bug 179981 has been marked as a duplicate of this bug. ***
*** Bug 236550 has been marked as a duplicate of this bug. ***
There are a couple of problems with using document.close() (or with using document.stop() as well, which by the way also works. 1) The name is not immediately obvious but more important 2) calling either close() or stop() does just that, it stops the load in its tracks. In order to load anything using this technique requires a timer to hold off the call to close() / stop() and to permit the Java script to do any loading at all !!
*** Bug 282218 has been marked as a duplicate of this bug. ***
*** Bug 282302 has been marked as a duplicate of this bug. ***
*** Bug 312863 has been marked as a duplicate of this bug. ***
Updating summary. No one is finding this because searching for document.write doesn't show this bug. There is no doc.write().
Summary: doc.open()/doc.write() without doc.close() does not stop throbber and trigger repaint → document.open()/document.write() without document.close() does not stop throbber and trigger repaint
*** Bug 331895 has been marked as a duplicate of this bug. ***
*** Bug 343147 has been marked as a duplicate of this bug. ***
Assignee: hjtoi-bugzilla → events
Priority: P3 → --
QA Contact: vladimire → ian
Target Milestone: Future → ---
(In reply to comment #39) > Isn't about time something was done about this bug !!!!! > I suggest you read the Bugzilla Ettiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(In reply to comment #40) > (In reply to comment #39) > > Isn't about time something was done about this bug !!!!! > > > I suggest you read the Bugzilla Ettiquette: > https://bugzilla.mozilla.org/page.cgi?id=etiquette.html I agree with 101355 compuserve guy. Let's see this bug fixed finally after S I X Y E A R S. The number of times I get asked "why is your page constantly transferring data" it's getting real old. Notice the number of bugs marked duplicates of this one. Doesn't that mean something?
Interestingly, if I create an iframe dynamically (a "friendly iframe") with src="about:blank" and iframeObj.contentWindow.document.writeln() a script out that contains document.writeln inside of it, then I call document.close() at the end of the script, the throbber keeps animating, as if the document.close was ignored. Is there a way to force the throbber to stop animating when all else fails? Is there a way to workaround this issue?
fyi, the only throbber that keeps spinning is on the tab.
Disregard comment #43. I just noticed that the main throbber kept animating if no other tabs were open.
Jonas, see comment 42. Related to your recent script loading changes maybe?
Don't think that my script loading changes is what's causing comment 42, since those only affected inline scripts. They're also changed now such that inline scripts execute more or less at the same place where they used to.
Netdragon and/or "Fix Firefox Status Bar Please", please file a new bug report for the problem you're seeing. It's orthogonal to this one, because even if the change proposed in the bug is made, your testcase will probably still fail to get an onload event.
Assignee: events → nobody
QA Contact: ian → events
You need to log in before you can comment on or make changes to this bug.