81980 - document.open()/document.write() without document.close() does not stop throbber and trigger repaint

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Nisheeth Ranjan]

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.

Comment 1

[Nisheeth Ranjan]

Attachment: Testcase: doc.write() without doc.close()

Comment 2

[Jesse Ruderman]

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?

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 4

[Nisheeth Ranjan]

Setting target milestone to 0.9.2

Comment 5

[Jesse Ruderman]

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.

Comment 6

[Nisheeth Ranjan]

Moving P2 and P3 bugs over to 0.9.3...

Comment 7

[Jesse Ruderman]

See also bug 77989, documents created using (a) doc.write without doc.close or 
(b) data:text/html wait 1.2 seconds before painting.

Comment 8

[Tom Mraz]

Not platform specific bug

Comment 9

[Chase Tingley]

*** Bug 91625 has been marked as a duplicate of this bug. ***

Comment 10

[Blake Ross]

Missed 0.9.3.

Comment 11

[Nisheeth Ranjan]

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.

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: testcase: load is called for frames, but not for frameset

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: testcase: no framesets

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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).

Comment 15

[Fabian Guisset]

*** Bug 108687 has been marked as a duplicate of this bug. ***

Comment 16

[Jesse Ruderman]

I think this should be wontfixed.  If javascript really does take a long time 
to write out a page, like the "search links" bookmarklet sometimes does, the 
throbber should animate during that time, just like it does while a normal page 
is loading.  It would be confusing to users if the throbber didn't animate 
while "search links" was in the middle of slowly document.writing the search 
results.  Also, it would be confusing to javascript programmers if the throbber 
stopped but the onload event didn't fire.  (The onload event can't fire until 
document.close() is called, because Mozilla can't tell whether the script plans 
to write another batch of html code.)

Comment 17

[Mike Kaply [:mkaply]]

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?

Comment 18

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 19

[Bob Clary [:bc] (inactive)]

eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. 

Comment 20

[Jesse Ruderman]

*** Bug 100638 has been marked as a duplicate of this bug. ***

Comment 21

[Heikki Toivonen (remove -bugzilla when emailing directly)]

No easy solution in sight, no major user impact that I know of. Futuring and
minusing.

Comment 22

[Tim Powell]

Comment #16 confuses me because it seems like Mozilla should know when there's
no more JavaScript code pending to execute. If that's true, why can't it just
stop animating the throbber at that point? From the end user perspective, that's
when the page load is complete. I find it odd that Mozilla should break behavior
of all previous browsers and continue animating the throbber just because
there's no call to document.close(). At worse, it'd seem a simple timeout could
be used, but I'd think that'd be unnecessary. In any case, this will cause user
confusion. Throbber animating means the page is still loading.

Comment 23

[Jesse Ruderman]

Tim: it would be equally confusing if the throbber stopped while javascript code
was in the middle of writing a page.  It's currently not common for javascript
to take several seconds to create a page, but I think it will become more common
in the future.

Mozilla currently does not thread javascript well, so it's hard to interact with
a page that is in the process of being created by javascript.  However, many
other browsers (IE and Opera and Netscape 4) do allow the user to see and
interact with pages as they are created by javascript.  I expect Mozilla to
thread javascript better in the future, and I also expect the other browsers to
fix the bug that the throbber is not animated while pages are created by javascript.

It might make sense to fix this bug for the simple case where a page replaces
itself by document.writing, since that happens quickly and cannot be followed by
a document.close, but always disabling the throbber on document.write would just
create a new bug.

Comment 24

[Tim Powell]

Jesse: I think you misunderstood what I was suggesting. It seems like Mozilla 
knows that JavaScript code is still executing (it hasn't reached the </script> 
or is in a function.) It's just logical that once it reaches the end of the 
page and there's no more JavaScript to excute the throbber should stop. This 
means that all the inline document.writes would complete and then the throbber 
would stop. This more closely ties page loading to the throbber, as users 
expect. It does mean that document.writes generated by events (onClick, etc.) 
after the page has loaded would not affect the throbber. In the case of your 
bookmarklet, it's building a new document using JavaScript, so the throbber 
would animate until it's done. But the end of the execution path should be 
pretty clear and not need to document.close to signal it.

Comment 25

[Nisheeth Ranjan]

*** Bug 77989 has been marked as a duplicate of this bug. ***

Comment 26

[Tom Mraz]

As the 77989 has been made a duplicate I make the summary a little bit broader.

Comment 27

[Boris Zbarsky [:bzbarsky]]

*** Bug 143019 has been marked as a duplicate of this bug. ***

Comment 28

[Bob Clary [:bc] (inactive)]

Looks like we have missed the train for 1.0.1. Can we retarget this for 1.2?

Comment 29

[Bob Clary [:bc] (inactive)]

*** Bug 179981 has been marked as a duplicate of this bug. ***

Comment 30

[Boris Zbarsky [:bzbarsky]]

*** Bug 236550 has been marked as a duplicate of this bug. ***

Comment 31

[osavill]

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 !!  

Comment 32

[Martijn Wargers (dead)]

*** Bug 282218 has been marked as a duplicate of this bug. ***

Comment 33

[Martijn Wargers (dead)]

*** Bug 282302 has been marked as a duplicate of this bug. ***

Comment 34

[:Gavin Sharp [email: [e-mail]]]

*** Bug 312863 has been marked as a duplicate of this bug. ***

Comment 35

[Jerry Baker]

Updating summary. No one is finding this because searching for document.write
doesn't show this bug. There is no doc.write().

Comment 36

[Jesse Ruderman]

*** Bug 331895 has been marked as a duplicate of this bug. ***

Comment 37

[Jesse Ruderman]

*** Bug 343147 has been marked as a duplicate of this bug. ***

Comment 39

[osavill]

Isn't about time something was done about this bug !!!!!

Comment 40

[Ryan Jones-Ward [:sciguyryan]]

(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

Comment 41

[Fix Firefox Status Bar Please]

(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?

Comment 42

[Brian 'netdragon' Bober]

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?

Comment 43

[Brian 'netdragon' Bober]

fyi, the only throbber that keeps spinning is on the tab.

Comment 44

[Brian 'netdragon' Bober]

Disregard comment #43. I just noticed that the main throbber kept animating if no other tabs were open.

Comment 45

[Johnny Stenback (:jst)]

Jonas, see comment 42. Related to your recent script loading changes maybe?

Comment 46

[Fix Firefox Status Bar Please]

I have a similar scenario to comment 42. A dynamically created iframe that's
created with src=about:blank and then some writeln's into it followed by a
document.close.

After that close though, there's later some further activity from code inside
that iframe which will create SCRIPT elements that load external JS files and
and also will create some DIV's and some SCRIPT blocks in the parent page (for
example, here are the highlights of some code inside the iframe):

var s=document.createElement('SCRIPT');
    s.text="some javascript statements";

var d=document.createElement('DIV');
    d.bla bla bla (set all div properties)

var b=parent.document.getElementById("someelementname");
    b.parentNode.appendChild(d);
    b.parentNode.appendChild(s);

Is Firefox automatically re-opening the closed document when something wants
to add something to the closed DOM ?

Is the content author required to re-close the page after dynamically adding
something to the DOM of an already closed page?

Comment 49

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 50

[Jesse Ruderman]

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.

Comment 62

[Boris Zbarsky [:bzbarsky]]

Fixed by bug 1489308: document.open no longer looks like a load, really, and no longer triggers the throbber at all.