From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a) Gecko/20020611 BuildID: Sometimes Stop button is not active, while ESC still stops page loading. I've tried to reproduce this bug, and I could only do it this way (may be there are other ways): when I load a page with full address (cnn.com) Stop button is active but when I load a page with address .com typing it without ".com" Mozilla try to load this_address.com (cnn -> cnn.com) and Stop button is inactive. Reproducible: Always Steps to Reproduce: Type "cnn" in the locationbar
Is this still a problem?
Alanjstr, I still see it (build 2003091209/WinXP Home SP1) if I type "cnn" or something like that (without the www. or .com) when I have keywords turned off. The stop button comes on while Mozilla is resolving the address, but once that is complete (it takes only a fraction of a second), the stop button becomes inactive, and the page loads with the stop button inactive. It is interesting that after DNS is complete, Mozilla does not replace the typed "cnn" in the URL bar with http://www.cnn.com, as I would expect. It continues to display "cnn" after the page is loaded, and it remains until a link is followed.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20031231 I can confirm this problem using 31/12/03 build on Mac OS X. "Stop" option in "View" menu is also greyed out.
Confirmed on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040105 Firebird/0.7+
Assignee: sgehani → jag
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
*** Bug 229901 has been marked as a duplicate of this bug. ***
This bug can be seen with <www.about.com> versus <about>. Requesting the former (complete domain) does not show the problem. Requesting the latter (Mozilla completes the domain) shows the problem. This is especially noticeable with a dial-up modem. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7RC2) Gecko/20040514
During page download after "successful" domain guessing not only the stop button is disabled but also the M-icon in the upper right corner is not animated. So I guess the GUI is not informed/signaled about download in progress after domain guessing. The ultimate;-) workaround for now instead of using the ESC key: Switching off Preferences|Navigator|Smart Browsing|Domain Guessing
This is still a browser problem, at least with SeaMonkey 1.1.7. Further, it was recently reported as a Thunderbird problem. See the thread "Does the Stop button work?" (started 19 Jan 08) in <news://news.mozilla.org:119/mozilla.support.thunderbird>. Since this appears to be a problem with both browser and mail-news, is it two bugs? Or is this single bug sufficient to fix it in both applications?
A variation of this bug is CONFIRMED in 3.0.6 (on Windows Vista). Famously happens on hotmail. You can click on a folder and the 'M' animation will churn for hours, and one of two outcomes happens: 1)you click on the active "Stop" button and nothing happens - The Birds still sing and everything still churns, churns, churns; or 2)the animation churns and the stop button is inactive and you can't get the damn thing to stop (except by clicking some other active link on the current page, forcing FF to load that page, and then stopping THAT second/different operation). Basically, then: 1)often the STOP button does not stop anything, or 2)during various loading operations the STOP button is not active. STOP should be like "kill -9" from the old Unix days - it should absolutely stop whatever is going on, no exceptions. The 3.0.6 STOP does not do this.
(Comment #9.1 - addendum to #9). The no-op of the Stop button in my listing seems to be related to AdBlock Plus. The churn churn churn with nothing happening, though animation of the "M" is active, and the Stop button no-ops seems to always be transferring "non-content" and this behavior of Stop disappears when I disable ABP. Am adding a note to Bug #467520. Do other contributors here also use ABP?
Dup of bug 21623?
Bug 21623 is about stopping animated GIFs, which involves what happens AFTER a page has completed downloading and rendering. Also, that bug might actually be an RFE even if it is marked NORMAL. This bug is about stopping the download of a page BEFORE the page has completed downloading and rendering. Furthermore, this is clearly a discrepancy in the operation of the software. Thus, I would think these are two different problems, neither of them being a duplicate of the other.
You need to log in before you can comment on or make changes to this bug.