2.39 KB, text/html
2.48 KB, text/html
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 ;)
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
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 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.
*** 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.
*** 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 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.
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 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".
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. ***
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 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
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 http://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1 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.
*** 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).
Keywords: nsbeta3, rtm → mozilla0.9, nsCatFood
Summary: page without </html> does not finish loading → bugzilla login form does not finish loading.
*** 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.
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+
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 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.
I meant this bug does NOT happen very consistently.
And if you get to the page by clicking "log-in" from the bugzilla.mozilla.org page, you will consistentaly never finish loading.
http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser 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 http://bugzilla.mozilla.org
Actually, I believe _any_ bug list is a 'hanger'.
Submitting bug comments also spins very reproducably.
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 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.
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; }
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); #endif 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. http://www.oeone.com/ 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.
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?
http://news.bbc.co.uk/ 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 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?
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: <table> <form> <tr><td><input type="select" blah></td></tr> </form> </table> But it'll do it on other things too.
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? ;-)
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.
Status: NEW → RESOLVED
Last Resolved: 18 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. 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).
morse: those are different bugs, not covered by this one.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 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, Steve
*** Bug 71472 has been marked as a duplicate of this bug. ***
verified: WinNT4 2001052204 Linux rh6 2001052213 Mac os9 2001051504
Status: RESOLVED → VERIFIED
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.