If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Some pages never finish loading (throbber never stops).

VERIFIED FIXED in mozilla0.9

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: R.K.Aa., Assigned: Chris Waterson)

Tracking

({crash})

Trunk
mozilla0.9
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments)

(Reporter)

Description

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

17 years ago
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.
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.

Comment 2

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

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

17 years ago
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.

Updated

17 years ago
OS: Linux → All

Comment 7

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

Comment 8

17 years ago
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.
seeing this as well. infinite throbbing gets annoying and distracting after the
first 5 minutes...nominating for rtm.
Keywords: rtm
Hardware: PC → All

Comment 10

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

17 years ago
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.

Comment 13

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

Comment 14

17 years ago
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]
(Reporter)

Comment 15

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

17 years ago
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-]
(Reporter)

Comment 17

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

Comment 18

17 years ago
*** Bug 62512 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 19

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

Updated

17 years ago
Keywords: mozilla1.0
(Reporter)

Comment 20

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

17 years ago
Created attachment 20822 [details]
Example login page without errors, and small modifications

Comment 22

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

Comment 23

17 years ago
Created attachment 20823 [details]
This time, the right one! My God I hate this kind of failures

Comment 24

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

17 years ago
Created attachment 20826 [details] [diff] [review]
patch to address reviewers comments

Comment 26

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

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

Comment 28

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

Comment 29

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

Comment 30

17 years ago
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
Keywords: nsbeta1

Comment 31

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

Comment 32

17 years ago
*** Bug 65165 has been marked as a duplicate of this bug. ***
10 dupes, adding mostfreq keyword
Keywords: mostfreq

Comment 34

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

Comment 35

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

Comment 36

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

Comment 37

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

Comment 38

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

Comment 39

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

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

Comment 41

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

Comment 42

17 years ago
CCing pollmann.
(Reporter)

Comment 43

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

Comment 44

17 years ago
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).
Keywords: nsbeta3, rtm → mozilla0.9, nsCatFood
Summary: page without </html> does not finish loading → bugzilla login form does not finish loading.
Whiteboard: [rtm-]

Updated

17 years ago
Blocks: 71668

Comment 45

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

Comment 46

17 years ago
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.

Updated

17 years ago
Keywords: crash

Updated

17 years ago
Blocks: 39310

Comment 47

17 years ago
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: nsCatFood → nsCatFood+
(Reporter)

Comment 48

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

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

17 years ago
I meant this bug does NOT happen very consistently.

Comment 51

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

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

Comment 53

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

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

Comment 55

17 years ago
Submitting bug comments also spins very reproducably.

Updated

17 years ago
Blocks: 74451

Updated

17 years ago
No longer blocks: 71668

Comment 56

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

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

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

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

Comment 62

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

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

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

Comment 66

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

Comment 67

17 years ago
*** Bug 74936 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 68

17 years ago
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.
(Assignee)

Comment 69

17 years ago
Created attachment 30118 [details] [diff] [review]
better fix?
(Assignee)

Comment 70

17 years ago
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?
(Assignee)

Updated

17 years ago
Blocks: 62589

Comment 71

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

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

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

Comment 74

17 years ago
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.
(Assignee)

Comment 75

17 years ago
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? ;-)
(Assignee)

Comment 76

17 years ago
Created attachment 30231 [details] [diff] [review]
patch from pavlov that fixes www.bbc.co.uk etc.
(Assignee)

Comment 77

17 years ago
Created attachment 30314 [details] [diff] [review]
fix PresShell bug, add logging to verify
(Assignee)

Comment 78

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

17 years ago
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
sr=jst
(Assignee)

Comment 81

17 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 82

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

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

Comment 83

17 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: bugzilla login form does not finish loading. → Some pages never finish loading (throbber never stops).
(Assignee)

Comment 84

17 years ago
morse: those are different bugs, not covered by this one.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 85

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

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

Comment 87

17 years ago
WooHoo!!!!  You guys rock!

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

Thanks to all involved,

Steve

Comment 88

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

Comment 89

17 years ago
verified:
WinNT4 2001052204
Linux rh6 2001052213
Mac os9 2001051504
Status: RESOLVED → VERIFIED

Comment 90

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

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

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