53956 - Some pages never finish loading (throbber never stops).

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[R.K.Aa.]

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

Comment 1

[Stephen P. Morse]

Yes, I'm definitely seeing this behavior on win32 as well.

It's not an autofill problem.  Try any other login form (such as 
people.netscape.com/morse/password.htm) and the username/password prefills just 
fine.

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.

Comment 2

[Stephen P. Morse]

Steps to reproduce the problem.

1. Go to http://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1

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

Comment 3

[R.K.Aa.]

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

Comment 4

[R.K.Aa.]

oops.. the "blink" i described seems unrelated to whether page finish loading or
not.

Comment 5

[Stephen P. Morse]

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

Comment 6

[selmer (gone)]

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.

Comment 7

[Stephen P. Morse]

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

Comment 8

[Stephen P. Morse]

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

So whatever it is that is unique about bugzilla must be in the headers and not 
the content.

Comment 9

[Mike Pinkerton (not reading bugmail)]

seeing this as well. infinite throbbing gets annoying and distracting after the
first 5 minutes...nominating for rtm.

Comment 10

[Gagan]

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.

Comment 11

[Stephen P. Morse]

Yes, I commented above about typing any key in any edit field causing the 
loading to terminate.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

I wonder if this bug is the race condition described in bug 54718.

Comment 13

[Asa Dotzler [:asa]]

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

Comment 14

[selmer (gone)]

Since 54718 got rtm-, I'd suggest that here as well.  We don't seem to have any
other example than bugzilla.

Comment 15

[R.K.Aa.]

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
http://www.cstr.ed.ac.uk/projects/festival/manual/festival_toc.html

Click a link - the place i see it as i write is after having clicked link to
"6 Installation".

Comment 16

[Phil Peterson]

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.

Comment 17

[R.K.Aa.]

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

Comment 18

[Stephen P. Morse]

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

Comment 19

[R.K.Aa.]

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

Comment 20

[R.K.Aa.]

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?

Comment 21

[HJ]

Attachment: Example login page without errors, and small modifications

Comment 22

[HJ]

Sorry, but that's the wrong one! Heck, where did that come from?
Oops, W3C Tidy generator, pick this one!

Comment 23

[HJ]

Attachment: This time, the right one! My God I hate this kind of failures

Comment 24

[HJ]

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.

Comment 25

[Stephen P. Morse]

Attachment: patch to address reviewers comments

Comment 26

[Stephen P. Morse]

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.

Comment 27

[Stephen P. Morse]

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.

Comment 28

[R.K.Aa.]

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

Comment 29

[Stephen P. Morse]

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

Comment 30

[Stephen P. Morse]

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 
nsbeta1

Comment 31

[Stephen P. Morse]

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

Comment 32

[Stephan Niemz]

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

Comment 33

[Matthias Versen [:Matti]]

10 dupes, adding mostfreq keyword

Comment 34

[Stephan Niemz]

Mid-air collission, I just wanted to add mostfreq, too. :)
But still updating the summary.

Comment 35

[Ben Bucksch (:BenB)]

Are you sure. it's the missing </html>? I've seen other pages not finishing to
load, which did have </html>, IIRC.

Comment 36

[Gagan]

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

Comment 37

[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 ;-)

Comment 38

[James Green]

Ben, see bug 39310 for this bug occuring on pages where </html> is sent. Same
effect, just not related. CC self.

Comment 39

[James Green]

I just turned off the HTTP Keep-Alive, and bugzilla bug pages now work fine
(throbber stops), but the URL
http://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1 still keeps the throbber
going. Most annoying.

Comment 40

[Gagan]

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

Comment 41

[harishd]

I don't think it's a parser problem but I will double check at my end.

Comment 42

[harishd]

CCing pollmann.

Comment 43

[R.K.Aa.]

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

Comment 44

[John Morrison]

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

Comment 45

[Stephen P. Morse]

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

Comment 46

[Stephen P. Morse]

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.

Comment 47

[selmer (gone)]

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.

Comment 48

[R.K.Aa.]

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.

Comment 49

[neeti]

I find that this bug does happen very consistently. Usually, If I type
http://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1 in the URLbar, it 
completes loading fine, however, I hit reload or shift+reload, it does not 
finish loading.

Comment 50

[neeti]

I meant this bug does NOT happen very consistently.

Comment 51

[Stephen P. Morse]

And if you get to the page by clicking "log-in" from the bugzilla.mozilla.org 
page, you will consistentaly never finish loading.

Comment 52

[James Green]

http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser lacks a
</body></html> and yet stops loading correctly.

Comment 53

[R.K.Aa.]

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 http://bugzilla.mozilla.org

Comment 54

[gabriel]

Actually, I believe _any_ bug list is a 'hanger'.

Comment 55

[Akkana Peck]

Submitting bug comments also spins very reproducably.

Comment 56

[Stephen P. Morse]

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)

Comment 57

[selmer (gone)]

I've found that http://quicken.excite.com/ recently began having this problem. 
In the 3/19 build, the throbber would spin until you scroll.  In later builds it
just keeps going.

Comment 58

[Stephen P. Morse]

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);
 #endif
   mDocumentLoading = PR_FALSE;
+  CancelAllReflowCommands();
   return NS_OK;
 }

Comment 59

[Stephen P. Morse]

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.

Comment 60

[Johnny Stenback (:jst)]

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.

Comment 61

[Johnny Stenback (:jst)]

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

Comment 62

[Stephen P. Morse]

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);
 #endif
   mDocumentLoading = PR_FALSE;
+  RemoveDummyLayoutRequest();
   return NS_OK;
 }

Comment 63

[Stephen P. Morse]

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.

Comment 64

[Stephen P. Morse]

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

Comment 65

[Johnny Stenback (:jst)]

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.

Comment 66

[Joseph Elwell]

This website never releases my throbber. http://www.oeone.com/
I'm using win2000 comm build 2001040204.

Comment 67

[Bradley Baetz]

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

Comment 68

[R.K.Aa.]

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.

Comment 69

[Chris Waterson]

Attachment: better fix?

Comment 70

[Chris Waterson]

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

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?

Comment 71

[James Green]

http://news.bbc.co.uk/ has been suffering from this problem in recent days. I
haven't tried with the patch from waterson.

Comment 72

[Nisheeth Ranjan]

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 http://news.bbc.co.uk/ 
and http://www.oeone.com/ 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?

Comment 73

[gabriel]

Bug 75270 has another example where the throbber keeps going for me, others
report a crash.

Comment 74

[Sam Rowe]

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:

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

But it'll do it on other things too.

Comment 75

[Chris Waterson]

Nisheeth: this doesn't fix bbc.co.uk or oeone.com; 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? ;-)

Comment 76

[Chris Waterson]

Attachment: patch from pavlov that fixes www.bbc.co.uk etc.

Comment 77

[Chris Waterson]

Attachment: fix PresShell bug, add logging to verify

Comment 78

[Chris Waterson]

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.

Comment 79

[Nisheeth Ranjan]

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!

Comment 80

[Johnny Stenback (:jst)]

sr=jst

Comment 81

[Chris Waterson]

Fix checked in.

Comment 82

[gabriel]

Linux build 2001041021. Looks good ! Nice one :-)

Verified a couple of bugzilla lists, throbber stops as expected.

Comment 83

[Stephen P. Morse]

Not completely fixed.  Several AOL properties still do not finish loading.

1. home.netscape.com
   - page comes up but throbber never stops
2. logging in to compuserve via following scenerio
   - go to www.compuserve.com
   - 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 
working.

Comment 84

[Chris Waterson]

morse: those are different bugs, not covered by this one.

Comment 85

[John Morrison]

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.

Comment 86

[Claudius Gayle]

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

Comment 87

[selmer (gone)]

WooHoo!!!!  You guys rock!

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

Thanks to all involved,

Steve

Comment 88

[neeti]

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

Comment 89

[Tom Everingham]

verified:
WinNT4 2001052204
Linux rh6 2001052213
Mac os9 2001051504

Comment 90

[Kent Paul Dolan]

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.

Comment 91

[Kent Paul Dolan]

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.

Comment 92

[benc]

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