From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011217 BuildID: 2001121708 There seems to be a point of no return when loading a given page, and that point isn't very far in. IMO, pressing stop or hitting Esc should stop the particular Mozilla window in its tracks. What happens instead is that (when clicking the stop button) the stop button will becme greyed out and Mozilla will continue on its merry way, loading the next page. Reproducible: Always Steps to Reproduce: 1. Click on a hyperlink 2. hit esc AND hit the stop button 3. Watch Mozilla ignore you Actual Results: Mozilla loads the next page Expected Results: Mozilla stops whatever it is doing.

could paint suppression be affecting this? eg, a page is loaded, and parsed and nearly laid out and is still suppressed. Then we hit stop.

Nope.

I've seen this before on dialup.. parser still processes and the stop button doesn't interupt the parser/renderer. Its not catching it in time?

->layout?

Always seeing it on Windows. You don't need to press Esc. Most times (depending on the connection speed) clicking the stop button doesn't prevent Mozilla from proceeding to the next page (Bugzilla is a common testcase) or a useless blank page. If you have a slow connection, you can notice that happening well before starting to retrieve the next page. OS->All.

Should one infer from the TargetMilestone that a 1.0 browser doesn't need a working Stop button?

WFM Build ID: 2002041903 (0.9.9+) trunk Windows 98. Tested on msnbc.com, which loads slowly on my bandwidth connection. Is there a testcase or a URL or something?

Finally I think it's a duplicate of bug 76495 (see similar dupes in that report). When trying to load a new page, Stop button is visually responding but the actual event is ignored. *** This bug has been marked as a duplicate of 76495 ***

Are you sure about that? That bug is only about the document not responding, everything outside the document still responds. Including the chrome. I don't think it's a dupe.

Imo, all these responsiveness problems when loading a page share a common reason. See also the discussion on bug 91822.