Closed Bug 91822 Opened 23 years ago Closed 22 years ago

Stop button doesn't stop via esc.

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 76495
mozilla1.1alpha

People

(Reporter: dylang, Assigned: bugs)

Details

I've been noticing this on and off for a few months now.  When I click a link,
and I know it was a mistake, pounding on the escape key does nothing whatsoever.
 Sometimes (in a new window) it will work, but most of the time the escape key
just doesn't seem to work the stop functionality at all.

Build ID 2001070521.
I have build 2001072105 in linux and this WFM
Try a new build
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
reopening and confirming with win2k build 20010722
Sometimes it works and sometimes not...
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → Keyboard Navigation
OS: Linux → All
Hardware: PC → All
Resolution: WORKSFORME → ---
confirming...
Assignee: asa → aaronl
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: doronr → sairuh
Didja try both clicking links in the first window you opened when you loaded the
opp, new windows, etc?

It only seems to happen in some, so you could be not seeing it if it's a race
condition.
maybe this is related to bug 81951
-> Ben, chrome issue
Assignee: aaronl → ben
is this still a problem? seems to wfm using 2001.08.06.08 bits [at least on
linux]. if it's still a problem, could you pls provide a sample url? thx.
This works for me as well.
I also think the reporter might be experiencing bug 81951.
It's still a problem in 2001080108.


I think it might be a problem of bug 81951 as Aaron says, though.
I see this problem on Linux milestone 0.93 and bug 81951 is marked for Win98 so
I don't think it's a duplicate.

Redhat 7.1/Gnome 1.2/XFree 4.01 blah blah blah...

Now that bug 81951 is fixed, can the reporter still reproduce the problem?

FIXED?
This seems to be covered by bug 76495 Still happens for me.
I think this is a more general problem.  The Moz UI has many unexpected
behaviours. When a page is loading, or the browser is "busy," clicking mail on
the bottom will do nothing.  Hitting escape for stop fails (the stop button
itself sometimes works).  Hitting reload after an aborted load doesn't try and
load the page (perhaps if there is no history, it should act as a "go" button if
location bar string != NULL).  And so on.

It'd be nice if we had a team of UI gangbusters to go around and make Moz not
have these sharp edges, which keep cutting into my web enjoyment.
(Note: all the problems I talked about exist in 2001092608 Linux)
Dylan_G: please file a bug about reload not working if page has never loaded yet.
Please cc: me as it anoys the heck out of me too.
Worksforme on Windows, which is the platform where it's supposed to work.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
However, it doesn't work from the time you specified new content to load until
the time the display starts showing the new content. That's exactly when you'd
want to stop loading - right away after you clicked the wrong link for example.

You shouldn't have to wait until the page starts displaying to hit stop.

It's also supposed to stop animations.
The "animation stop" is another bug.
And this is not working at one point of page loading but it should working
reopening !

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Interesting. OK. 
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.1
Or dupe of bug 103758 (should be fixed for 0.9.8)??

*** This bug has been marked as a duplicate of 76495 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → DUPLICATE
marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.