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

NEW
Unassigned

Status

()

Core
DOM: Events
16 years ago
a year ago

People

(Reporter: Nisheeth Ranjan, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [eapp])

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 35456 [details]
Testcase: doc.write() without doc.close()

Comment 2

16 years ago
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.
(Reporter)

Comment 4

16 years ago
Setting target milestone to 0.9.2
Target Milestone: --- → mozilla0.9.2

Comment 5

16 years ago
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.
(Reporter)

Updated

16 years ago
Priority: -- → P3
(Reporter)

Comment 6

16 years ago
Moving P2 and P3 bugs over to 0.9.3...
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 7

16 years ago
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

16 years ago
Not platform specific bug
OS: Windows 2000 → All
Hardware: PC → All

Comment 9

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

Comment 10

16 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Reporter)

Comment 11

16 years ago
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
Created attachment 48962 [details]
testcase: load is called for frames, but not for frameset
Created attachment 48963 [details]
testcase: no framesets
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

Comment 15

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

Comment 16

16 years ago
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

16 years ago
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

Updated

16 years ago
Whiteboard: [eapp]
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.
Keywords: nsbeta1+
Blocks: 125136

Comment 19

16 years ago
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. 
Keywords: nsbeta1+ → nsbeta1

Comment 20

16 years ago
*** 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

Comment 22

16 years ago
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

16 years ago
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

16 years ago
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.
(Reporter)

Comment 25

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

Comment 26

16 years ago
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. ***

Comment 28

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

Comment 29

15 years ago
*** Bug 179981 has been marked as a duplicate of this bug. ***
*** Bug 236550 has been marked as a duplicate of this bug. ***

Comment 31

14 years ago
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. ***

Comment 35

12 years ago
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

Comment 36

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

Comment 37

11 years ago
*** Bug 343147 has been marked as a duplicate of this bug. ***
Blocks: 260249
Duplicate of this bug: 332446
Assignee: hjtoi-bugzilla → events
Priority: P3 → --
QA Contact: vladimire → ian
Target Milestone: Future → ---
Blocks: 326183
Comment hidden (me-too)

Comment 40

11 years ago
notechnicalvalue
(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?
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?

Updated

10 years ago
Duplicate of this bug: 260249

Updated

10 years ago
Duplicate of this bug: 387942
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

10 years ago
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

Updated

9 years ago
Blocks: 403566

Updated

9 years ago
Blocks: 427771

Updated

9 years ago
Duplicate of this bug: 471784
Duplicate of this bug: 505259

Updated

8 years ago
Duplicate of this bug: 512659
Duplicate of this bug: 605937

Updated

6 years ago
Duplicate of this bug: 631129

Updated

5 years ago
Duplicate of this bug: 737226
Duplicate of this bug: 251529
Duplicate of this bug: 923619
Duplicate of this bug: 360704
Duplicate of this bug: 623880
Duplicate of this bug: 771270
See Also: → bug 1277348
You need to log in before you can comment on or make changes to this bug.