Closed
Bug 53956
Opened 24 years ago
Closed 24 years ago
Some pages never finish loading (throbber never stops).
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: spam, Assigned: waterson)
References
()
Details
(Keywords: crash)
Attachments
(6 files)
2.39 KB,
text/html
|
Details | |
2.48 KB,
text/html
|
Details | |
5.12 KB,
patch
|
Details | Diff | Splinter Review | |
569 bytes,
patch
|
Details | Diff | Splinter Review | |
904 bytes,
patch
|
Details | Diff | Splinter Review | |
2.10 KB,
patch
|
Details | Diff | Splinter Review |
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•24 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•24 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>>
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 not.
Comment 6•24 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•24 years ago
|
OS: Linux → All
Comment 8•24 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.
Comment 9•24 years ago
|
||
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•24 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•24 years ago
|
||
Yes, I commented above about typing any key in any edit field causing the loading to terminate.
Comment 12•24 years ago
|
||
I wonder if this bug is the race condition described in bug 54718.
Comment 13•24 years ago
|
||
*** Bug 57545 has been marked as a duplicate of this bug. ***
Comment 14•24 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•24 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•24 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•24 years ago
|
||
*** Bug 59551 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
*** Bug 62512 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•24 years ago
|
||
*** Bug 63033 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: mozilla1.0
Reporter | ||
Comment 20•24 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•24 years ago
|
||
Comment 22•24 years ago
|
||
Sorry, but that's the wrong one! Heck, where did that come from? Oops, W3C Tidy generator, pick this one!
Comment 23•24 years ago
|
||
Comment 24•24 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•24 years ago
|
||
Comment 26•24 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•24 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•24 years ago
|
||
*** Bug 65041 has been marked as a duplicate of this bug. ***
Comment 29•24 years ago
|
||
*** Bug 66921 has been marked as a duplicate of this bug. ***
Comment 30•24 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•24 years ago
|
||
*** Bug 66700 has been marked as a duplicate of this bug. ***
Comment 32•24 years ago
|
||
*** Bug 65165 has been marked as a duplicate of this bug. ***
Comment 34•24 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•24 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•24 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•24 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•24 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•24 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•24 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•24 years ago
|
||
I don't think it's a parser problem but I will double check at my end.
Comment 42•24 years ago
|
||
CCing pollmann.
Reporter | ||
Comment 43•24 years ago
|
||
*** Bug 71928 has been marked as a duplicate of this bug. ***
Comment 44•24 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).
Summary: page without </html> does not finish loading → bugzilla login form does not finish loading.
Whiteboard: [rtm-]
Comment 45•24 years ago
|
||
*** Bug 72437 has been marked as a duplicate of this bug. ***
Comment 46•24 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.
Comment 47•24 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•24 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•24 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•24 years ago
|
||
I meant this bug does NOT happen very consistently.
Comment 51•24 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•24 years ago
|
||
http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser lacks a </body></html> and yet stops loading correctly.
Reporter | ||
Comment 53•24 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•24 years ago
|
||
Actually, I believe _any_ bug list is a 'hanger'.
Comment 55•24 years ago
|
||
Submitting bug comments also spins very reproducably.
Comment 56•24 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•24 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•24 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•24 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.
Comment 60•24 years ago
|
||
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
Comment 61•24 years ago
|
||
*** Bug 73162 has been marked as a duplicate of this bug. ***
Comment 62•24 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•24 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•24 years ago
|
||
*** Bug 72145 has been marked as a duplicate of this bug. ***
Comment 65•24 years ago
|
||
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•24 years ago
|
||
This website never releases my throbber. http://www.oeone.com/ I'm using win2000 comm build 2001040204.
Comment 67•24 years ago
|
||
*** Bug 74936 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 68•24 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•24 years ago
|
||
Assignee | ||
Comment 70•24 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?
Comment 71•24 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•24 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•24 years ago
|
||
Bug 75270 has another example where the throbber keeps going for me, others report a crash.
Comment 74•24 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="select" blah></td></tr> </form> </table> But it'll do it on other things too.
Assignee | ||
Comment 75•24 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•24 years ago
|
||
Assignee | ||
Comment 77•24 years ago
|
||
Assignee | ||
Comment 78•24 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•24 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
Comment 80•24 years ago
|
||
sr=jst
Assignee | ||
Comment 81•24 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 82•24 years ago
|
||
Linux build 2001041021. Looks good ! Nice one :-) Verified a couple of bugzilla lists, throbber stops as expected.
Comment 83•24 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•24 years ago
|
||
morse: those are different bugs, not covered by this one.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 85•24 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•24 years ago
|
||
*** Bug 74571 has been marked as a duplicate of this bug. ***
Comment 87•24 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•24 years ago
|
||
*** Bug 71472 has been marked as a duplicate of this bug. ***
Comment 89•24 years ago
|
||
verified: WinNT4 2001052204 Linux rh6 2001052213 Mac os9 2001051504
Status: RESOLVED → VERIFIED
Comment 90•24 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•24 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•22 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.
Description
•