Closed Bug 74571 Opened 19 years ago Closed 10 years ago

Opening Mozilla with setting "start with blank page" never turns off "stop"


(SeaMonkey :: UI Design, defect, trivial)

Not set


(Not tracked)



(Reporter: xanthian, Assigned: buhr+mozilla)


(Blocks 1 open bug, )


(Whiteboard: [patchlove])


(1 file, 2 obsolete files)

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

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

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.
Whiteboard: dupeme
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 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
> 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.
Resolution: DUPLICATE → ---
Whiteboard: dupeme
-> Future.
Severity: normal → trivial
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
Keywords: mozilla1.0
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 → ---
Target Milestone: --- → mozilla1.0
+qawanted (probably need confirmation on multiple platforms)

Does anyone who understands the internals think this is a depends of bug 19073?
Keywords: qawanted
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 [ 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.
Target Milestone: mozilla1.0 → Future
*** 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. ***
Blocks: 73967
Attached patch Fix (obsolete) — Splinter Review
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]

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
Product: Browser → Seamonkey
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 ""
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

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.
Keywords: qawanted
Assignee: firefox → buhr
Component: General → XP Apps: GUI Features
QA Contact: bugzilla → guifeatures
Attachment #168463 - Flags: review?(
andrew, would this be fixed by the move to toolkit?  if not, is the current patch useful?
Severity: minor → trivial
Duplicate of this bug: 372515
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.

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.


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,'toolbar=yes'): the stop button goes through the proper enabled/disabled cycle.

Attachment #168463 - Attachment is obsolete: true
Attachment #168463 - Flags: review?(neil)
Attachment #326180 - Flags: superreview?(jag)
Attachment #326180 - Flags: review?(jag)
Component: XP Apps: GUI Features → UI Design
Whiteboard: [patchlove]
Attachment #326180 - Flags: review?(jag) → review?(neil)
Attachment #326180 - Flags: superreview?(jag)
Attachment #326180 - Flags: superreview+
Attachment #326180 - Flags: review?(neil)
Attachment #326180 - Flags: review+
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.
Closed: 19 years ago10 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.
Duplicate of this bug: 536801
You need to log in before you can comment on or make changes to this bug.