Closed Bug 53956 Opened 24 years ago Closed 24 years ago

Some pages never finish loading (throbber never stops).


(Core :: Layout, defect, P3)






(Reporter: spam, Assigned: waterson)




(Keywords: crash)


(6 files)

20000922something and some builds now:

The behaviour of autofill has changed from bad to worse lately; for instance in
bugzilla logins.

Some days ago it would fill in the login a little while after i started typing
in the login field. So i ended up with a double login.

Now nothing is filled in to login field, only passwordfield autofills, and that
happens only after i start typing in the login-field. If i wait for something to
happen and don't type at all - nothing happens.

Using the SEA tar.gz version since it's the only one with a reasonable size to
download these days ;)
Yes, I'm definitely seeing this behavior on win32 as well.

It's not an autofill problem.  Try any other login form (such as and the username/password prefills just 

Problem is with the loading of the bugzilla login page.  Note that it never 
finishes loading as indicated by both the throbber in the upper right and the 
progress bar in the lower left.  Since the loading never terminates, 
OnEndDocumentLoad is never getting called, and so password manager is not being 
invoked to do the prefill.

It appears that typing any character in any field on the form will cause the 
loading to terminate and the prefill to occur.  The symptoms you reported were 
not exactly accurate.  Both the username field and the password field will get 
prefilled once you type a character to force the loading to terminate.  But 
since you typed that character into the username field, you've apparently caused 
it to replace the prefill for the username.  Had you stopped the load by typing 
a character into the password field instead, you would have seen the username 
field get prefilled.  Furthermore, if you stop the load by typing a character 
into the bug# field, then both the username and the password will get prefilled.  
Also you can terminate the load by hitting the stop button and then too the 
prefill of both username and password will occur.

I definitely want to nominate this bug for nsbeta3 (although I expect it to be 
an uphill battle) since failure to complete the load will probably cause other 
problems as well.  As the reporter said, things have "changed from bad to worse 
lately" so this must be a recent regression.

Updating Summary field to accurately describe the problem and reassigning.
Assignee: morse → gagan
Component: Autofill → Networking
Keywords: nsbeta3
QA Contact: sairuh → tever
Summary: autofill of forms only half work → bugzilla login form does not finish loading.
Steps to reproduce the problem.

1. Go to

<<Note that throbber never stops>>

2. Fill in username and password and press login

3. Answer yes to password-manager dialog for saving the password

4. Reload the page

<<Note that throbber never stops and username/password are not being prefilled>>

5. Stop the page loading by pressing the stop button in the chrome.

<<Note that prefill now occurs>>
ahh if this is about things not finishing loading, i filed a bug about that as
well - bug 53864, with some additional observations.
(Yet a phenomena is that when a bug-page finally loads and throbber stops, it
will often give a "blink" after it has fully rendered: It completely vanishes,
then reappears again, this time to stay.)
oops.. the "blink" i described seems unrelated to whether page finish loading or
*** Bug 54346 has been marked as a duplicate of this bug. ***
What's unique about bugzilla?  I don't see this happening on bugscape at all.
The bugscape login page comes up nicely prefilled on first paint.
OS: Linux → All
*** Bug 53864 has been marked as a duplicate of this bug. ***
Whatever it is that is unique about bugzilla, it's not in the content.  I just 
tried copying the content of that page to a local file and then opened it with 
the browser and had no problem.  To convince myself that the local file had 
nothing to do with it, I then copied it up to a server and tried.  Again no 

So whatever it is that is unique about bugzilla must be in the headers and not 
the content.
seeing this as well. infinite throbbing gets annoying and distracting after the
first 5 minutes...nominating for rtm.
Keywords: rtm
Hardware: PC → All
Very strange. I do see networking issuing the OnStop correctly but nobody seems
to pick that up... Interestingly if I hit any key on the edit fields
(user/passwd) the page stops loading. Seems like an event thats stuck between
getting fired and getting notified. cc'ng dougt the event-maestro. Clearly that
means this isn't networking, but I'd let this sit with me till I can figure out
who's the right owner.
Yes, I commented above about typing any key in any edit field causing the 
loading to terminate.
I wonder if this bug is the race condition described in bug 54718.
*** Bug 57545 has been marked as a duplicate of this bug. ***
Since 54718 got rtm-, I'd suggest that here as well.  We don't seem to have any
other example than bugzilla.
Whiteboard: [need info]
I see this (or something extremely similar) happen several other places. Didn't
think more sites were relevant to add, since the bug is fairly visible. Here a
sample I stumbled across today: Throbber goes on throbbing forever, but the page
is long since downloaded:

Go to

Click a link - the place i see it as i write is after having clicked link to
"6 Installation".
PDT marking [rtm-]. We see this with bugzilla too, but the easy workarounds are
to click on a link on the page or click the Stop button.
Whiteboard: [need info] → [rtm-]
*** Bug 59551 has been marked as a duplicate of this bug. ***
*** Bug 62512 has been marked as a duplicate of this bug. ***
*** Bug 63033 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
Seems a common denominator on affected pages is lack of a </html> tag.
The error surfaced medio September.
Did Moz got less fault tolerant, or were changes made to Bugzilla?
Sorry, but that's the wrong one! Heck, where did that come from?
Oops, W3C Tidy generator, pick this one!
Additional comment:
1 - missing DTD, conform W3C.
2 - </tr></table> closes to many times.
3 - <form> inside <table> is causing problems.
4 - <td valign=center align=left> should be <td valign="middle" align="left">
5 - attributes meed double quoted strings.
6 - wrong placed <a href=> tag.
7 - missing closing tag for <body>.
8 - missing closing tag for </html>.
9 - use CSS for integration of Accessibility.

"The power of the Web is in its universality. Access by everyone regardless of
disability is an essential aspect."
-- Tim Berners-Lee, W3C Director and inventor of the World Wide Web.
Above patch addresses the reviewers comments.  Howeve I have some comments on 
those comments:

> I'd probably check for type="text" (or type="") first in the |case "input"|, 
> since we don't care what button or how many clicks if isn't a textbox.

I can turn that argument around and say "we don't care what type of element it 
is if it isn't a double click."  Unless somebody has done a study to show that 
there are more instances of double-clicks than there are of textboxes, the 
ordering here is really insignificant.  However, since it makes you happier, 
I've reversed the ordering.

> I didn't really look over the commented out code since that will be handled
> in another bug.  However, I noticed that when there are multiple entries, a
> dialog is opened...I think a menu-type widget similar to what IE has is much
> preferable

That was exactly my thought as well, and is another reason that I commented out 
this code for the present.

> Also, point 1 doesn't seem to be much of a problem -- why not just create a
> new .properties file?

I didn't say it couldn't be done, I just said it wasn't "simple", meaning it 
was not as simple as adding an entry to the existing .dtd file.  Adding a new 
.properies file means adding an entry to a manifest so that's yet another file 
that needs to be changed.  However this is all a moot point since I plan on 
using a drop-down menu and that doesn't involve any localizable strings.
Oops, I'm in the wrong bug report.  Please ignore my last two postings (patch 
and comments) -- they were meant for bug 48982.  Sorry about creating noise in 
this bug report.
*** Bug 65041 has been marked as a duplicate of this bug. ***
*** Bug 66921 has been marked as a duplicate of this bug. ***
This one keeps getting dups.  And it affects password-manager because the 
prefill can't occur until the page finishes loading.  So nominating this for 
Keywords: nsbeta1
*** Bug 66700 has been marked as a duplicate of this bug. ***
*** Bug 65165 has been marked as a duplicate of this bug. ***
10 dupes, adding mostfreq keyword
Keywords: mostfreq
Mid-air collission, I just wanted to add mostfreq, too. :)
But still updating the summary.
Summary: bugzilla login form does not finish loading. → page without </html> does not finish loading
Are you sure. it's the missing </html>? I've seen other pages not finishing to
load, which did have </html>, IIRC.
ccing some more people here. If its true that its only on /html cases then I'd 
like to let layout/parser area do some investigation on this. Do we trigger 
something based on the /html tag? I'd start with that...
Assignee: gagan → harishd
Parser does not make any decision based on /html. In fact, it does not even care 
for <html>,<body>,</html>,</body> ( since they're optional per spec. ). This is 
no way connected to parser. 

Back to gagan ;-)
Assignee: harishd → gagan
Ben, see bug 39310 for this bug occuring on pages where </html> is sent. Same
effect, just not related. CC self.
I just turned off the HTTP Keep-Alive, and bugzilla bug pages now work fine
(throbber stops), but the URL still keeps the throbber
going. Most annoying.
we now have a family of pages that won't finish loading becuz of a number of 
reasons. Everything from a missing /html to no content-length and other great 
chaotic events... setting tfv of 1.0
Target Milestone: --- → mozilla1.0
I don't think it's a parser problem but I will double check at my end.
CCing pollmann.
*** Bug 71928 has been marked as a duplicate of this bug. ***
Unless someone has evidence that, har, a missing </html> is preventing this 
page for loading, I'm restoring the prior summary.

Also nominating for "catfood". This has been like this for >6 months, and it
would be good to at least get a handle on why. (And see bug 39310, now closed
in favour of specific bugs, for a list of other page loading problems).
Summary: page without </html> does not finish loading → bugzilla login form does not finish loading.
Whiteboard: [rtm-]
Blocks: 71668
*** Bug 72437 has been marked as a duplicate of this bug. ***
And the dups are getting worse.  Latest one reports a crash due to this.  We 
really need to get this in for 0.9.  Please reconsider the target milestone 
which is currently set at 1.0.
Keywords: crash
Blocks: 39310
Gagan, I'm moving this to nscatfood+.  It seems to be happening on more and more
sites and it really makes us look bad. It would be great if we could get
mozilla0.9.1 instead of mozilla1.0 on this.
Keywords: nsCatFoodnsCatFood+
several things can trigger this bug, missing /html being only one.
Bug 52798 is interesting. After it was marked fixed, all the (genuine) dups of
it i tested now show this behaviour: None completed loading before timeout
occures after approx 3 minutes.
I find that this bug does happen very consistently. Usually, If I type in the URLbar, it 
completes loading fine, however, I hit reload or shift+reload, it does not 
finish loading.
I meant this bug does NOT happen very consistently.
And if you get to the page by clicking "log-in" from the 
page, you will consistentaly never finish loading. lacks a
</body></html> and yet stops loading correctly.
neeti is right - it's inconsistant.
After loading the URL mentioned above, i re-tested URL's and testcases from bug
52798 and suddently they all finished loading. (2 hours old build)

However: For another seemingly 100% reproducable "hanger":
click "View Bugs Already Reported Today" link at

Actually, I believe _any_ bug list is a 'hanger'.
Submitting bug comments also spins very reproducably.
Blocks: 74451
No longer blocks: 71668
I don't understand this yet, but I do have an analysis of the sequence of events 
that are occuring which result in the page not finishing loading.  I just posted 
that analysis in bug 72186 (see my comment of 2001-04-03 23:23)
I've found that recently began having this problem. 
In the 3/19 build, the throbber would spin until you scroll.  In later builds it
just keeps going.
FWIW, I can make this bug go away by adding a call to CancelAllReflowCommands() 
at the point that the nsPresShell detects that the loading has finished -- 
namely at the end of PresShell::EndLoad().

Y:\mozilla\layout\html\base\src>type \all.dff
Index: nsPresShell.cpp
RCS file: /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v
retrieving revision 3.381
diff -u -r3.381 nsPresShell.cpp
--- nsPresShell.cpp     2001/03/27 23:59:56     3.381
+++ nsPresShell.cpp     2001/04/04 20:40:28
@@ -3117,6 +3117,7 @@
   CtlStyleWatch(kStyleWatchPrint, mStyleSet);
   mDocumentLoading = PR_FALSE;
+  CancelAllReflowCommands();
   return NS_OK;
Just to make it clear, I'm not proposing the above patch at all because it 
introduces problems with other sites.  I'm just making the observation that it 
will allow the bugzilla login page to complete loading.
I bet this bug belongs to Nisheeth, it's probably a problem with removing the
dummy layout request from the loadgroup when we're done reflowing, Nisheeth sez
he'll fix this for mozilla0.9. Reassigning.
Assignee: gagan → nisheeth
Component: Networking → Layout
Target Milestone: mozilla1.0 → mozilla0.9
*** Bug 73162 has been marked as a duplicate of this bug. ***
Another patch that will make this bug go away is the following.  ANd it doesn't 
seem to have the bad effects of the previous patch I posted above.

Y:\mozilla\layout\html\base\src>type \all.dff
Index: nsPresShell.cpp
RCS file: /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v
retrieving revision 3.381
diff -u -r3.381 nsPresShell.cpp
--- nsPresShell.cpp     2001/03/27 23:59:56     3.381
+++ nsPresShell.cpp     2001/04/04 20:40:28
@@ -3117,6 +3117,7 @@
   CtlStyleWatch(kStyleWatchPrint, mStyleSet);
   mDocumentLoading = PR_FALSE;
+  RemoveDummyLayoutRequest();
   return NS_OK;
I should point out that I discovered the above patch re RemoveDummyLayoutRequest 
before reading jst's comment.  Sounds like we are saying the same thing.
*** Bug 72145 has been marked as a duplicate of this bug. ***
Steve, I think you're on the right track, but I don't think your patch is safe
as is, I think you need at least an if (mRCCreatedDuringLoad == 0) around that
call, maybe more checks too. This is code I'm not very familiar with so I can't
say for sure, Nisheeth should know more details about this.
This website never releases my throbber.
I'm using win2000 comm build 2001040204.
*** Bug 74936 has been marked as a duplicate of this bug. ***
As i commented in dup bug 53864: I first saw this bug in the morning build from
Sept. 20th 2000.

At the time i usually downloaded a build a day. What causes this was likely
checked in sometime between the 19th and morning build on the 20th.
Attached patch better fix?Splinter Review
The problem is that leaving the dummy request in the load group can potentially 
block the OnStopRequest() from firing on the main URL. Which means that EndLoad
() will never be called, and that PresShell::mDocumentLoading will never be set 

I think that the right way to fix this is to *only* leave the dummy layout 
request in the load group while there are unprocessed reflows. As soon as there 
are no pending reflows left to process, we *must* yank the dummy request. If 
subsequent reflows are enqueued, we'll add the request back (and yank it again 
as soon as those requests are processed). This guarantees that we'll keep the 
load alive long enough so that all reflows are processed, but won't end up in a 
situation where the load is blocked from stopping.

This fixes the bugzilla problem, as well as a sporadic timeout I was seeing 
with inline-script doing document.write(). Is there a good frameset test that I 
could try to make sure that subdocs still work right?
Blocks: 62589 has been suffering from this problem in recent days. I
haven't tried with the patch from waterson.
Good catch, waterson!  The latest patch definitely works for the Bugzilla login 
page and the Bugzilla bug list pages.  It doesn't seem to be the complete 
solution though, because even with the patch, pages like 
and do not finish loading.

I am ok with removing the dummy layout request whenever there are no pending 
reflows.  But, we shouldn't create and destroy the request every time.  I think 
we should cache the request per presshell and keep adding/removing the cached 
request to/from the load group as the document load progresses.

What say you?
Bug 75270 has another example where the throbber keeps going for me, others
report a crash.
FWIW, I can recreate this bug -very- consistantly with a PHP application that
I'm writing. Even down to the "first char in a form terminates" bit. This
application is definatly sending /html. It definately hates:

<tr><td><input type=&quot;select&quot; blah></td></tr>

But it'll do it on other things too.
Nisheeth: this doesn't fix or; just bugzilla for now. :-/

As to caching the layout request: sure. I'll leave that as an exercise for the
reader. You're coding again, right? ;-)
Nisheth, I've updated the patch to switch the #ifdef DEBUG_nisheeth printf()'s
into regular old PR_LOG() stuff. (I was debugging some of pavlov's stuff last
night, and needed to see it all in one file.) Anyway, I used that to determine
that we *aren't* actually creating very many dummy layout requests. ``Normal''
pages create one. Tinderbox creates two. Even loading nsCSSFrameConstructor.cpp
in LXR only created about fifty.

So, in the grand scheme of things, I think that caching the layout request is
probably not worth doing.
r=nisheeth for the latest patch.  Chris, in light of your latest detective work, 
I agree that caching the request isn't worth it.

Re-assigning this to you so that you get the credit for the fix.

Thanks for jumping in and fixing this!
Assignee: nisheeth → waterson
Fix checked in.
Closed: 24 years ago
Resolution: --- → FIXED
Linux build 2001041021. Looks good ! Nice one :-)

Verified a couple of bugzilla lists, throbber stops as expected.
Not completely fixed.  Several AOL properties still do not finish loading.

   - page comes up but throbber never stops
2. logging in to compuserve via following scenerio
   - go to
   - click on computing
   - fill in username and password and click submit
   - next page comes up but throbber never stops.

Updating summary to not mention bugzilla page specifically since that one is now 
Resolution: FIXED → ---
Summary: bugzilla login form does not finish loading. → Some pages never finish loading (throbber never stops).
morse: those are different bugs, not covered by this one.
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Steve, there are no less than two "meta" bugs tracking the problem of 
pages not completing loading: bug 39310 and bug 74451. See if they cover
what you note, and otherwise file a bug and make it block those. There 
are different root causes that trigger this, and it's better to fix them
one at a time.
*** Bug 74571 has been marked as a duplicate of this bug. ***
WooHoo!!!!  You guys rock!

(The quicken site is also well behaved on the 4/11 build.)

Thanks to all involved,

*** Bug 71472 has been marked as a duplicate of this bug. ***
WinNT4 2001052204
Linux rh6 2001052213
Mac os9 2001051504
It is still the case when opening a new, blank browser page, that the
stop light never goes hazed.  Was that expected to be fixed with this
repair?  That particular opening method doesn't display a throbber.

Finishing that thought, build 2001052020 for win32, blank browser page
brought up either by setting that as the opening page, and launching
Mozilla, or by using the File -> New Navigator Window menu item of the
browser.  This was all reported in bug 74571, which someone later marked
as a duplicate of this bug 53956, so I was expecting to see it fixed when
this bug was marked fixed.

I won't change the bug status, but perhaps it should either be returned
to needs repair status, or bug 74571 should be revived as an independent
bug, by one of the maintainers for this bug.

*** Bug 55641 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.