Closed Bug 74571 Opened 19 years ago Closed 10 years ago
Opening Mozilla with setting "start with blank page" never turns off "stop"
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1) Gecko/20010323 BuildID: 2001032319 There is a common problem across Mozilla, that pages being entered don't seem to "stop" in any reasonable amount of time. The easy way to troubleshoot this is probably from the about:blank page. Reproducible: Always Steps to Reproduce: 1.Use preferences to set the new browser window to blank, the startup window to blank. 2.Exit Mozilla. 3.Launch Mozilla. 4. Notice that the "stoplight" never gets hazed out. Actual Results: Window failed to recognize that the loading action was complete. Expected Results: A window should sooner or later stop loading when all the data has arrived. This is one flavor of a bug widely visible in using Mozilla; most pages continue loading action long after the last data has arrived. Very likely this continual busy state is related to slowness to load pages, various crashes, and whatever.
I've seen this but I don't see this with the about:blank page. I do see it on Netscape's home page with current (2001040309) builds. Nonetheless I believe this is a dupe anyway. There's bound to be some bug of the form "throbber keeps spinning or won't stop". and this is certainly not a search bug.
I don't see this with about:blank either (Win NT). The bug for endless loading in other cases would be bug 53956.
i'm jusr going to mark this a dupe, thanks clarence *** This bug has been marked as a duplicate of 53956 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
> The bug for endless loading in other cases would be bug 53956. No, that is specifically for bugzilla (until someone tried to morph it by changing the title).
not a dup.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
-> Networking I see the same on Linux. Note that the throbber does not spin. Minor, but very visible ("homepage") -> mozilla1.0 nomination.
Assignee: matt → neeti
Severity: trivial → minor
Component: Search → Networking
OS: Windows 98 → All
QA Contact: claudius → benc
Hardware: PC → All
Summary: Opening Mozilla with setting "start with blank page" never turns off "stop". → Opening Mozilla with setting "start with blank page" never turns off "stop"
Target Milestone: Future → ---
+qawanted (probably need confirmation on multiple platforms) Does anyone who understands the internals think this is a depends of bug 19073?
Hi, I'm new here and this is my second attempt at debugging Mozilla. I'm just brainstorming for you, so you're welcome to skip over this if it is wasting your time. Any suggestions are welcome. I helped out a bit with bug 88650 and one of the problems was that when Mozilla couldn't find the file in a temp directory, it would go through an infinite loop. For all practical purposes this would freeze Mozilla--at least it would for me. So when I copied the required file into the required directory, it would play [...it was a midi file...]. In Netscape 4.79, Netscape would just complain and not do anything and wait for a user event, whereas Mozilla wouldn't know when to stop. I believe that somewhere deep in the code there is function that is missing an if() statement to check for missing files, or completed files. It may be also noteworthy to point out that Netscape 4.79 would only play the midi file once. The reason I decided to copy a file into an expected directory is because the console would continually print an error message about a file that wasn't found. If you go to the bug mentioned above, you'll probably get a better idea of what I mean. I left my browser version and a testcase there. My recommendation [eventhough it is an uneducated one] is to have the stop button or stop events have priority over all others, much like a killall -9 [or similar]. In other words, if the browser is still waiting for a reply from a server, and the user wants to quit, it would be useless for everybody to have to wait till the page starts to load then allow him the choice of pressing stop. The stop event should be a cancel for any loading of anything. I hope this helps. I'm not too good with terminology, so if some of it seems confusing, let me know, or ask questions.
*** Bug 104880 has been marked as a duplicate of this bug. ***
->xp-apps, maybe somone can say if they own this problem.
Assignee: neeti → blaker
Component: Networking → XP Apps: GUI Features
QA Contact: benc → sairuh
This isn't xpapps, we just stop when we're told to stop. -> radha?
Assignee: blaker → radha
Target Milestone: Future → ---
This bug is not about throbber continuing to rotate but about the stop button remaining as enabled when it should be disabled. Looking little bit deeper, it appears that nsBrowserStatusHandler is not found in the list of listeners that docloader keeps to notify about document loads. It does appear that docloader does send out onStateChange() notifications to the listeners for blank pages, but I don't see the browser as one of the listeners. I only see nsChromeTreeOwner and nsDocshell as listeners and therefore browser does not get notified. In any case, session history (which I own and manage is not related to this at all). Neither do I think that docshell can play a role here. Someone in the browser team or docloader should look into why the browser is missing in the listener list and/or why the notifications are not being sent.
Assignee: radha → sgehani
Component: XP Apps: GUI Features → Browser-General
-> blake for a look
Assignee: sgehani → blaker
*** Bug 85647 has been marked as a duplicate of this bug. ***
Call loadURI() even when the startup-URI is about:blank. This way the Stop button is disabled when the page finishes loading.
Comment on attachment 131441 [details] [diff] [review] Fix While this patch fixes the bug, it causes a 12ms hit on startup time. I don't think this is acceptable. So I'm marking it obsolete.
Attachment #131441 - Attachment is obsolete: true
Looks like this one-liner chrome patch fixes the problem in Seamonkey (though it might not have always been this simple). Basically, the code is now all there to special-case "about:blank" and not turn on and off the stop button when "loading" it. We just have to make the initial state of the stop button disabled for it to work properly. I tested this fix with a Mozilla nightly with homepage set to "www.google.com" and "about:blank" and specifying "Blank" and "Home" as the initial page in all combinations, and it all seemed to work correctly. (Note that this bug is apparently not present in Firefox.)
Oh, perhaps I should add that (without the patch applied) I can verify that this bug *does* occur on current nightlies under both Linux and Windows XP. In contrast to the bug 104880 reporter, I've been able to verify it under both platforms in *both* the Modern and Classic themes. For this reason, I think I'll -qawanted, unless someone really thinks we need to verify this on even more platforms. Note that I'm talking about the bug as originally reported here and in bug 104880---on the *initial* window, if the initial window's initial page is set to "Blank" (or to "Home" with an "about:blank" homepage), and on new windows, if new windows' initial pages are set to "Blank" (or to "Home" with an "about:blank" homepage), the stop button is initially enabled and does not become disabled until another page (even a blank page) is loaded. I have not seen any problems with explicitly loading a blank page either by entering "about:blank" in the location bar or by Go->Home when the homepage is set to "about:blank", or anything similar. The stop button works correctly in these cases. And in no case does the throbber keep running.
Assignee: firefox → buhr
Component: General → XP Apps: GUI Features
QA Contact: bugzilla → guifeatures
andrew, would this be fixed by the move to toolkit? if not, is the current patch useful?
Severity: minor → trivial
the patch is still needed (and works) for suiterunner. navigator.xul is in suite/browser/ now.
Since this bug is receiving attention again, this is just to confirm that it still exists as of the 2007051309 nightly build for MS-Windows; I just downloaded, installed, and tested that latest nightly to be sure. xanthian.
I just also saw this "'stop' never turns off" behavior on a newly opened "untitled" tab, but three tries to reproduce it failed. There may be some race condition at work, but that makes the bug be not "about:blank" specific, perhaps, and perhaps that's a useful clue. FYI xanthian, hmm, this bug just celebrated its sixth birthday, too. Environment: SeaMonkey 2007052208; WinXP 64 bit Media Center edition 2005; AMD Turbion64 chipset.
Peter, could you look into granting r+sr for this trivial UI change? On a trunk build of the suite, without the patch, the problem as originally described remains. If the initial page is blank (whether selected using the "blank page" radio button or using an "about:blank" homepage), the stop button starts enabled and is never disabled. With the attached patch, the stop button works correctly for the initial browser window, new browser windows, and new tabs, whether the preferences are set to start with a real homepage (in which case the stop button is enabled and disabled as expected), the special "about:blank" homepage (stop button stays disabled), or explicitly to a blank page using the radio button (again, stop button stays disabled). Additionally, if preferences are set to go to last page visited, it doesn't look as if a blank page is ever eligible to be the last page visited, and the stop button appears to work correctly with other pages (enabled then disabled). Finally, the patch doesn't appear to adversely affect windows opened with window.open(...,'toolbar=yes'): the stop button goes through the proper enabled/disabled cycle. Thanks.
Comment on attachment 326180 [details] [diff] [review] in suite, make initial state of stop button disabled > oncommand="BrowserStop();" observes="canStop" [Sadly canStop doesn't exist, otherwise it would have fixed this bug.] >- tooltiptext="&stopButton.tooltip;"/> >+ tooltiptext="&stopButton.tooltip;" >+ disabled="true"/> Feel free to insert this attribute earlier to avoid the /> edit.
Thanks for the review, but the patch is almost 2 years old, and I can't duplicate the behavior on the latest SeaMonkey comm-central nightly, so marking resolved/worksforme.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 10 years ago
Resolution: --- → WORKSFORME
Well I was able to reproduce the bug, and the fix, so I've checked it in. Pushed changeset fd992fdcc830 to comm-central.
Resolution: WORKSFORME → FIXED
You need to log in before you can comment on or make changes to this bug.