bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

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



UI Design
17 years ago
8 years ago


(Reporter: Kent Paul Dolan, Assigned: Kevin Buhr)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [patchlove], URL)


(1 attachment, 2 obsolete attachments)



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

Comment 1

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


17 years ago
I don't see this with about:blank either (Win NT).
The bug for endless loading in other cases would be bug 53956.

Comment 3

17 years ago
i'm jusr going to mark this a dupe, thanks clarence

*** This bug has been marked as a duplicate of 53956 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 4

17 years ago

Comment 5

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

Comment 6

17 years ago
not a dup.
Resolution: DUPLICATE → ---
Whiteboard: dupeme

Comment 7

17 years ago
-> Future.
Severity: normal → trivial
Ever confirmed: true
Target Milestone: --- → Future

Comment 8

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


17 years ago
Target Milestone: --- → mozilla1.0

Comment 9

17 years ago
+qawanted (probably need confirmation on multiple platforms)

Does anyone who understands the internals think this is a depends of bug 19073?
Keywords: qawanted

Comment 10

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


16 years ago
Target Milestone: mozilla1.0 → Future

Comment 11

16 years ago
*** Bug 104880 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
->xp-apps, maybe somone can say if they own this problem.
Assignee: neeti → blaker
Component: Networking → XP Apps: GUI Features
QA Contact: benc → sairuh

Comment 13

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

Comment 15

16 years ago
-> blake for a look
Assignee: sgehani → blaker

Comment 16

16 years ago
*** Bug 85647 has been marked as a duplicate of this bug. ***


16 years ago
Blocks: 73967

Comment 17

15 years ago
Created attachment 131441 [details] [diff] [review]

Call loadURI() even when the startup-URI is about:blank. This way the Stop
button is disabled when the page finishes loading.

Comment 18

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

Comment 19

14 years ago
Created attachment 168463 [details] [diff] [review]
make initial state of stop button disabled

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.)

Comment 20

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


14 years ago
Assignee: firefox → buhr
Component: General → XP Apps: GUI Features
QA Contact: bugzilla → guifeatures


14 years ago
Attachment #168463 - Flags: review?(neil.parkwaycc.co.uk)

Comment 21

11 years ago
andrew, would this be fixed by the move to toolkit?  if not, is the current patch useful?
Severity: minor → trivial


11 years ago
Duplicate of this bug: 372515

Comment 23

11 years ago
the patch is still needed (and works) for suiterunner.  navigator.xul is in suite/browser/ now.

Comment 24

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


Comment 25

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

Comment 26

10 years ago
Created attachment 326180 [details] [diff] [review]
in suite, make initial state of stop button disabled

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.

Attachment #168463 - Attachment is obsolete: true
Attachment #168463 - Flags: review?(neil)
Attachment #326180 - Flags: superreview?(jag)
Attachment #326180 - Flags: review?(jag)


10 years ago


10 years ago
Component: XP Apps: GUI Features → UI Design
Whiteboard: [patchlove]


8 years ago
Attachment #326180 - Flags: review?(jag) → review?(neil)


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

Comment 28

8 years ago
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.
Last Resolved: 17 years ago8 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.


8 years ago
Duplicate of this bug: 536801
You need to log in before you can comment on or make changes to this bug.