Closed Bug 614304 Opened 14 years ago Closed 12 years ago

ESC key aborts XMLHttpRequest and WebSocket

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 20

People

(Reporter: ivan, Assigned: Gavin)

References

(
URL
)

Details

(Keywords: testcase, user-doc-needed)

Attachments

(1 file, 1 obsolete file)

patch
2.24 KB, patch
dao
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

Pressing ESC aborts open XMLHttpRequests in Firefox.  This doesn't happen in other browsers (except in WebKit, but only if the XHR was initiated before the page finished loading).

Aborting XHRs on ESC is a bad idea for at least two reasons:

1. Most AJAX applications don't retry requests; if a user hits ESC during an XHR, they might see broken behavior.

2. This makes Comet-over-XHR more annoying to implement, requiring an event handler to capture all ESCs.  (I know it's not absolutely necessary in a good implementation.)

I imagine there are a few applications out there that like this behavior, but they probably have an "abort XHRs on ESC" handler installed for the other browsers.  There's a good chance they might not even have to make any changes.

Reproducible: Always

Steps to Reproduce:
1. http://ludios.net/browser_bugs/esc_stops_xhr.html
2. Press ESC
3. Observe open XHR aborted instantly
Actual Results:  
XHR is aborted instantly

Expected Results:  
Ideally, the XHR would stay open.
ESC cancels all open networking requests and that's a decision from Firefox.
Gecko just follows the cancel request if I'm right.

And I'm sure that we had another dupe bug report with a comment from bz that I can't find at the moment.
I discovered an entertaining variation on this bug. I get this behavior too, which was surprising and unexpected, but more interestingly, when the request is sent to localhost, the server ends up receiving it, processing it, and returning a response, even though Firefox calls the xhr error handler immediately. When the request is sent to a remote server, it's cancelled before being sent.

This made debugging more than a little interesting.

I would favor making ESC not cancel AJAX requests by default. If it's decided that it should still do so, then at least it should consistently cancel the request before it's sent, and the error handler should receive something to indicate that it was in response to user action; perhaps the event which triggered the cancel would be a fine thing to include.
Version: unspecified → 3.6 Branch
Reporter, Firefox 4.0.1 has been released, and it features significant improvements over previous releases. Can you please update to Firefox 4.0.1 or later, and retest your bug? Please also create a fresh profile (
http://support.mozilla.com/kb/Managing+profiles), update your plugins (Flash, Java, Quicktime, Reader, etc) and update your graphics driver and Operating system to the latest versions available. 

If you still continue to see this issue, please comment. If you do not, please close this bug as RESOLVED > WORKSFORME

filter: prefirefox4uncobugs
Yup still happens.
Version: 3.6 Branch → 4.0 Branch
Status: UNCONFIRMED → NEW
Component: General → DOM
Ever confirmed: true
Keywords: testcase
Product: Firefox → Core
QA Contact: general → general
Version: 4.0 Branch → 2.0 Branch
Comment 3 is correct.  The ESC key just cancels all network requests associated with the currently selected tab.  There are no provisions for treating some requests specially.  This is something that happens on the Firefox UI and necko level, with no interaction with the DOM at all, so this is in the wrong component...

_If_ the Firefox folks want to change the behavior of escape, then we need a separate bug on necko APIs to allow a different behavior here.
Component: DOM → General
Product: Core → Firefox
QA Contact: general → general
Yeah, I think we should remove this "feature". Having a key to abort network requests seems like an expert feature that at least shouldn't be enabled by default. IMHO it should ideally be removed completely. People can always write an extension to re-add it if desired.

cc'ing some people to up the visibility on this one.
Hmm.  So it used to be that ESC was the same as just hitting the stop button, but nowadays we just don't show the stop button after the page has loaded.  Perhaps we should start ignoring the ESC key when the stop button is not visible...  What should happen if people customize back to separate stop/reload buttons?
I don't think this is intentional from the front-end side of things... Esc should cancel the initial pageload activity, but not things afterward. There are probably some ambiguities there, but I don't believe there's any strict definition of what Stop/ESC has to do.

The suggestion in comment 9 sounds fine to me.
> Esc should cancel the initial pageload activity, but not things afterward.

Historically, that's not the case.  Not only has esc stopped any network requests after pageload, but it also stops image animations....
Blocks: 676881
qwebirc is another app that has a workaround for this (landfill's irc client doesn't).

bz: re comment 7, could you possibly file a bug on necko for that? the people in this bug are 99% victims, you are one of the few people close to the dev side of things.

From my perspective as a user, I have used <esc> to stop network loads as well as animations. However, I also use <esc> to get rid of the <find-toolbar> and the fact that I sometimes get rid of the <find-toolbar> and sometimes kill the web page (really IRC client) that I'm using is rather unfortunate (modality sucks).

otoh, I thankfully just got an irccloud account, so I no longer have to worry about accidentally shooting my foot of while using the <find-toolbar> with moznet/foxymonkies.
Incidentally IRCCloud still relies on XHR streaming for people who don't have flash or on-by-default WebSocket support. (a minority now)
The Facebook Chat team is getting bit by this problem as well.  Our long-poll XHR requests are cancelled by ESC.

Unfortunately there's no elegant workaround for this.  We're going with something like this:

  window.addEventListener('keydown', function(e) {(e.keyCode == 27 && e.preventDefault())})

... for lack of a better solution, but I'm definitely concerned about the unanticipated side-effects of canceling ESC events *everywhere*.  What makes this worse is that bugs this causes will be really difficult for engineers not familiar with this change to diagnose.  E.g. "wtf? Why can't I ESC-cancel app menu drop downs anymore ...???".  That sort of thing.

Comment 9 and Comment 10 sound about right to me.
I have an app which uses SignalR. ESC closes connections opened to the hub, which is really frustrating, hence this key used to exit full screen mode for some views.
ESC also closes web sockets connections. This is a bad deal for rich applications that allow the user to interact with the escape key.  (And those are just the kind of apps that are likely to be using a lot of XHR and persistent connections.) Comment 14 +1
Also interested in seeing this bug fixed. Luckily, I discovered this early during my implementation of web sockets. I needed to add my own auto-reconnect and disconnect code because I wanted to use the ESC key for other behavior.
blocking-kilimanjaro: --- → ?
blocking-kilimanjaro: ? → ---
Does this still happen in nightlies? It appears that the esc key no longer cancels *any* network requests at *any* point during a page load.

During the initial load the "stop" button still cancels all network requests, but that button goes away once the page is done loading.
At least that's the behavior I'm seeing on OSX. It might be different on other platforms.
I don't know about XMLHTTPRequest, but I'm still able to repro this for WebSockets in "Firefox 16.0a1 (2012-06-18)" on OSX.

Here's my repro:
1. Go to http://gamma.firebase.com/mike  (this will establish a websocket connection to gamma.firebase.com)
2. Open the "Net" tab in FireBug.
3. Press ESC.

Result: Each time you press ESC, the existing websocket connection to gamma.firebase.com connection is killed and Firebase has to spawn a new one.
Product: Firefox → Core
QA Contact: general → general
Summary: ESC key aborts XMLHttpRequest → ESC key aborts XMLHttpRequest and WebSocket
Sorry, I missed comment 7.

Firefox currently calls nsIWebNavigation.stop(nsIWebNavigation.STOP_ALL). Having Esc do nothing when the stop button is disabled sounds reasonable. I don't think "Esc to stop animations" is a use case we need to continue to support.
Product: Core → Firefox
QA Contact: general → general
That would be awesome! The esc key is getting used more and more on the web these days, and such sites are basically playing russian roulette in Firefox right now.
Created a new account as I haven't used Bugzilla since 2004/2005.
And no my email addresses weren't in the account recovery system anymore.

I just wanted to point out many of the comments regarding the ESC button are made with (Eternal Sept.) little historical knowledge.

1. ESC wasn't, and still isn't known by the vast majority of users.
   (people are now mouse-centric, and never press the escape key)
   So consider the ESC key a professional/power user feature.

2. Traditionally web-browsers had the stop button selectively stop certain content.
   (Some people have noted and suggested that above.)

3. Traditionally web-browsers had the ESC key stop all activity!
Some of us may recall using Mozaic, Netscape, and IE in the mid 90's, and how the stop button would not stop the Blink or Marque tags. (Proprietary tags in HTML 2 or 3?)
Regardless many users then learned the ESC key would stop those tags.
But most users found pressing a key annoying.
  (And that was 15 years back, when DOS was still used, and Debian fit on
   5 floppies, NoSLx for installing Debian when it grew to 7 floppies.)
Programs like Scott Lemon's Proxomitron gained immense standing within the internet communities as a way to scrub that kind of undesired content off the web pages.

So the ESC key helped bring a powerful message, and in a way important feedback.

I'd like to see Mozilla keep the ESC key as it has been traditionally used through out the history of the web.  I'm well aware Firefox changed the ESC key to no longer kill all connections on a webpage several years back, and this has annoyed me to the point of occasionally using both Chromium, and Opera, and sometimes Chrome.

4. If Firefox is to deviate and make the ESC key a mirror of the stop button...
Then I'd strongly suggest putting a checkbox in the tools -> options
And let the user decide, even though the average user never changes any options.
  [x] ESC key mirrors Stop Button  (Safest setting for XML content)
  [ ] ESC key stops all connections in an active tab page.

5. ESC addon... such an addon should not be relied on for a critical function.
   Average users don't understand why their addons always seem to stop working.
   This perception is mostly due to the new "Versioning" system.
   And in part from addon developers who stop support, because of version-fatigue.


I apologize for the long comment, but I feel Firefox is loosing it's balance to maintain a well design browser designed for both the average users and power users.
Gavin, any chance you could take this bug? This seems like relatively small amount of work for high value.

Everyone else: No one is arguing that what firefox does here is the right thing. We all agree that it's a bug, that's why this bug hasn't been closed as invalid or wontfix.
Assignee: nobody → gavin.sharp
Firefox fires "error" event on XMLHttpRequest, i think, "abort" event will be better for this situation, this will help with detection
I wanted to add that this is not a "bug" but a feature: in fact, I fell upon this page because I was trying to see if anyone else experiences behavior where the ESC key takes a long time to actually do anything (if anything is done--sometimes pages just keep loading). Removing this functionality from those of us who like to control the browser, rather than the other way around, is going to **** enough off when already the problems in plumbing have left too many instabilities within the browser: perhaps web services don't like having users control activity on their machines, but I certainly do. My2sense.
Web developers don't mind users having the ability to control their machines. We believe the escape button specifically should be within our control to override - for example, if we pop up an inline dialog, we want to make the escape button close that dialog without disconnecting the client. That makes the most sense from a usability perspective.

Not to put words in the mouths of people working on Firefox, but as a web developer, we'd be totally fine with configuration, even configuration allowing you to change ESC back to the current functionality. It's OK if your connection closes when you close the dialog - we just don't want that to happen to the majority of our users by default.
The browser knows when XHR or WS are running, so let the browser show a prompt when ESCaping (and the site finished loading) to ask whether the user wants to stop all connections from the current website. 

If you want to prevent the browser from executing the default behaviour (and e. g. bind ESC to closing an HTML (not JS) dialogue), just Event.preventDefault() (or Event.stopPropagation()) on ESC-keypress. If the user presses ESC multiple times (be aware that a user might want to close several HTML modal dialogues so there could be false-positives) or holds it down for e. g. 2 seconds, ignore the Event.preventDefault() and display a prompt nonetheless.

That's how it should work, IMO.
Just an aside to those who want the ESC key to continue to operate like the old days, and cut off all XHR requests and Websocket connections immediately - most web apps suffering through this behavior are going to immediately initiate websocket reconnection, like Mike mentioned (comment 21), or continue making subsequent XHR requests. What has the ESC key accomplished in that case? It doesn't make much sense after initial page load. 
I would vote for Gavin's suggestion in comment 22.
at least, a chance to distinguish "ESC abort" and a network error will be helpful
Discussion in bug 213377 and bug 284140 make me think that fixing this per comment 22 will likely upset some power-users. Keyboard-only functionality is not going to be widely relied upon, though, so a convincing argument can be made that that concern does not outweigh the concerns raised in this bug, and we should find some other way to address that particular use case (if we think it deserves to be addressed).
Attached patch patch (obsolete) — — Splinter Review 
This is a pretty straightforward backout of bug 284140's patch.
Attachment #694114 - Flags: review?(dolske)
Gavin: Do you also need to change the mac-specific accelerator just below?
Yes, I do! (I had no idea Cmd+. was "stop" on Mac o_O)
Also: potentially changing HandleAppCommandEvent's call to BrowserStop to be a goDoCommand("Browser:Stop"), but that only affects things like dedicated stop buttons on "multimedia" keyboards, so probably doesn't matter too much.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #36)
> Also: potentially changing HandleAppCommandEvent's call to BrowserStop to be
> a goDoCommand("Browser:Stop")

That doesn't work, because Browser:Stop is not the right type of command.
Attached patch patch — — Splinter Review 

        Attachment #694153 -
        Flags: review?(dolske)

    
    

    
  
Can the XHR-/Socket-/Animation-Stop behaviour be implemented with an addon, and if not, can we implement APIs to do so? Thus, power-users have no reason to complain ;-).

    
  

        Attachment #694153 -
        Flags: review+

    
    

    
  
(In reply to Florian Bender from comment #39)
> Can the XHR-/Socket-/Animation-Stop behaviour be implemented with an addon

Yes, very easily. Adding e.g. a shift+Esc shortcut that calls BrowserStop() is very straightforward.

        Attachment #694114 -
        Attachment is obsolete: true

        Attachment #694114 -
        Flags: review?(dolske)

        Attachment #694153 -
        Flags: review?(dolske)

    
    

    
  
https://hg.mozilla.org/integration/mozilla-inbound/rev/3a4372abccab
Target Milestone: --- → Firefox 20
Version: 2.0 Branch → unspecified

    
    

    
  
Perhaps try to compromise and offer power-users the option of toggling the ESC functionality between your default of 'advert-pleasuring placebo-"esc"-key', and an escape key that actually escapes out of the current state properly, as in full stop.


I've programmed a fair bit in the past (now days I just lurk and dabble...) but I took, and still take pride in coding.  I would code what's right, do a good job, and offering what people want and want to use.

So, I don't understand why current FF coders think making the key into an idiot switch will be desirable...  All it does is show a certain lack of regard/respect for your users and pandering to perv.., whoops I mean adverts, and that should really make people pause!



A HUGE percentage of FireFox users are in 3rd worlds, they don't have money, or internet bandwidth, and mast have dialup?  And it's the power-users and dialup-users (your majority) that want the escape to stop useless unseen junk from downloading and using Their Bandwidth that They Pay for on Their Computer.
 (Please consider this a friendly reminder of who your customers/users are.)
en.wikipedia.org/wiki/Firefox#Distinctions


The average (N.American) person never (and as a SysAdmin I do mean NEVER) touches the ESC key.  So logically you should give the option.

Also a reminder that FF appears to been in steady decline since May 2012
It appears IE, Safari, Opera, even generic "Other" browsers have had a reprieve during those same months, but Not FF and for me that's pretty telling!...
 (StatCounter Global Stats, Top Browsers Per Country, 12 months)
gs.statcounter.com/#browser-ww-monthly-201112-201212


So should comment 41 be taken as an indication that FF is broken, and it's time to fork (code-wise) FireFox?
Personally, I don't see anything new in FF as useful (much less desirable) in roughly the past 2 years!  So I really can't see a fork as being viable.
I'm starting to fear FF is lost, and that history (ie. NN6) could be repeating...


Well, I just typed a whole lot so here's the full rant:
If things don't change soon I probably try Opera again, I bet it's changed a lot since I started using FF in Oct 2004...  But don't worry, I will still lurk here and try to get you to fix things even though I don't think I should have to bother to take the time and trouble to do this!
This is because a good software policy is:  "the customer is always right."

PSS.  Dear FF stop with the Major Version Number garbage, your losing users fast.
And you've lost FREE addon Programmers faster then a cat can shed hair!
I could believe that vermin "cats" can shed faster then the human eye can see.

    
  
Blocks: 824248

    
    

    
  
Jason: Instead of ranting, act. 

See Bug 824248. Is that something you can live with?

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/3a4372abccab
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED

    
  
Keywords: dev-doc-needed, 
          
            user-doc-needed
Depends on: 825486

    
    

    
  
I see I'm a bit late to the party, but can we fix this in a way that satisfies both the people who want Esc to stop image animation and the people who don't want it to stop network activity?

Esc used to call stop(nsIWebNavigation.STOP_ALL). After this patch, it does nothing after the page has finished loading. If we instead make it call stop(STOP_CONTENT) after page load has finished, it'll stop image animation without stopping ongoing network activity.

I tested with a modified version of the test page, and it works perfectly there -- image animation stops while the XHR request succeeds.

(According to MDN, STOP_CONTENT also stops "pending Javascript timeouts". This does not appear to be true.)

If this is something we can live with, then I'll file it as a separate bug and write the patch for it.

    
    

    
  
dagger, please do that or create an extension that would have Esc stop animation.

    
    

    
  
I wrote an add-on that adds a Shift+Esc shortcut that behaves the way Esc used to:
https://addons.mozilla.org/en-US/firefox/addon/superstop/

    
    

    
  
Gavin, your add-on will be useful if one wants to stop all network activities, and I will use it too, but I want to also be able to simply stop animations of gif images. I think this should be the default action of the Esc key after the page is done loading.

    
    

    
  
You can use my extension solely for stopping images after the fact. It makes Shift+Esc behave exactly as Esc used to.

    
    

    
  
Right, the extension is good for people who want the old Esc behavior, but I think pressing Esc in the browser itself should stop image animation (especially since it has done that for the past decade or so). My suggestion above was for a way to do it without causing this bug.

    
    

    
  
I for one use it alot
& would like to see it behind about:config flag
(if you guys are hell bent on removing this important feature)
instead of an addon
but Gavin, your add-on will be useful if one wants to stop all network activities, and I will use it too(please keep it updated)

    
    

    
  
Please note that using "esc" to do *anything* other than simply firing an key event to the page is a bad idea once the page has loaded. *Very* many webpages use the "esc" key to do various UI things, and they do this with good reason since that is UI that is intuitive to users.

So if we tie stopping network events or stopping animations etc to this key, it will mean that these things happen any time that users close some part of the website UI. This seems like a bad idea even if it's something that you have to opt in to.


That said, there are addons that bring back the old behavior. This is the power or firefox. Building in every conceivable feature into the browser is just going to keep it bloated and slow down development. That's why we created addons.

I understand that this is more work for people that do want this feature. But keep in mind that for people that just want their website to work, and won't be messing around with about:config, keeping this feature in the browser is indirectly a cost to them.

    
    

    
  
You made a good point, Jonas. Then a better approach would be to create an extension that can expose a keyshortcut or a button for stopping image animations quickly (and only for this).

    
    

    
  
(In reply to Roman R. from comment #53)
> You made a good point, Jonas. 

I disagree.
He said "*Very* many webpages use the "esc" key to do various UI things"

Please show me samples (URLs) of such webpages.

These (third party neutral) websites samples can Not be designed/tweaked/altered/coded/scripted/made by anyone who had/has anything to do with Bugzilla, Addons, Mozilla, etc.

Note: if a website just disables the Esc key and nothing else then it does not count, because his statement clearly says "do various UI things"...

But I would still be very interested in seeing any 3rd party neutral webpages that do disable the ESC key.

    
    

    
  
(In reply to Florian Bender from comment #43)
> Jason: Instead of ranting, act. 
> 
> See Bug 824248. Is that something you can live with?

Dear Florian Bender
I had already helpfully answered your inquiry.
 "If things don't change soon I probably try Opera again"

My concern with this bug and with the direction that Firefox seems to be heading is a repeat of Netscape 6+.
I could mention many older browsers but I'm sure there's some number of people who post to Bugzilla that can recall pre-browser war days back in the 1990's.

Let me clarify what I do mean by 'repeat of NN6+', the features and bugs got away from what the average person wanted, things no longer seemed to work intuitively for the average user.  From what I heard from people and observed back then (as a electronics repair tech turned computer technician) was that the NN programmers had their heads in the clouds, and lost complete touch with reality of the average person, who was using "their" product, and all the new features wasn't wanted by the average user, and ignoring the average users when they did post comments, and send emails.

Yes I know enough of the NN to Phoenix to FF history to say hey, stop and look where your headed, history does and can repeat.  And yes, a few people on Bugzilla will be Miffed that I wrote the above, but that's the view from out here.
I just don't want to be stuck with IE again all the while hoping that Opera gains ground and doesn't simply disappear, or another resurrection of FF happens.
I know Google Chrome is gaining ground, but people try it and tell me they won't use GC because they can't print anything, or find anything, or everything's buried 10 clicks deep with GC, which could be FF's saving grace.

So Florian you asked what can I live with?  How about another fork in the road?

    
    

    
  
I'm sorry to inform you that you may not be an "average" Firefox user (no offense). 


Let's stop any discussion as it will not yield to any new result.

    
    

    
  
(In reply to Florian Bender from comment #56)
> I'm sorry to inform you that you may not be an "average" Firefox user (no
> offense). 

How about you try reading before posting.
That's the second time you posted something stupid that I already stated.

I never said I was average, and if you think the discussion is over then that's fine by me.

    
    

    
  
So it seems we are optimizing Firefox for the use case where a user is using a webpage with a dialog, they want to close the dialog with ESC, the page has animations /and/ the user does not want to stop the animations. We are doing this at the expense of the ability to stop animations at all.

I think that trade-off goes too far. I think the negative impact from people accidentally stopping image animations when they wanted to close a in-page dialog would be relatively small (because most such websites won't be using animated images, and in any case people use the mouse and not the keyboard, right?) compared to the negative impact on people who have discovered and used the animation cancelling feature for the 10 years we've had it.

    
    

    
  
Hi! Given some of the negative comments, I just wanted to send a big thanks for fixing this.  Firebase actually handled this gracefully (by just reconnecting), but we still had a number of users notice and report it to us as a bug in Firebase (they'd see errors in the console whenever somebody used the ESC key). Searching github or stackoverflow for references to this bug suggests a lot of other projects have had similar experiences. :-)

    
    

    
  
This is such a tricky issue, and I want to thank you for attempting to fix it.  On my own website, clubcompy.com, the compy does LOAD and SAVE functions using AJAX calls back to the server.  I was shocked one day to learn that pressing Esc terminated the AJAX connections, and I wound up similarly trapping Esc at the document level like the Facebook Chat team did to suppress the default behavior.

Reading all the comments, I came to understand how many different ways I overload the use of Esc in my personal web usage.  I use it instinctively to stop the page load, I use it to dismiss the Ctrl-F find bar.  And, I bind to it in my own web applications as a catch-all cancel key.

My first reaction on how to proceed was "Firefox should just copy whatever the other browsers are doing."  Or, "Mozilla should get the W3C involved to weigh in and ask that all the vendors agree on a uniform standard for cancellation."

But, on deeper reflection, I think I would prefer that Mozilla leads here and goes its own way.  Like others, I instinctively feel that the old-school mapping of Esc to "Stop" is Right.  We need a quick key to mash and make it just stop what it was doing.  

I also see now that the world has moved on.  New users don't know about Esc, and web apps like mine blithely bind to it.  I only accidentally discovered its full effects on FF.  And Esc is overloaded beyond just the browser.  On my Windows keyboard, for instance, Ctrl+Esc is an accelerator for opening the start menu, and Ctrl+Shift+Esc is an accelerator for opening the Task Manager.  Esc is a complicated key, and as power users I feel we need to concede some ground here.

With how much JavaScript now runs onDomReady before onLoad, and how much AJAX runs after onLoad, I think it is seriously dangerous today to take (or not take) action on Esc regardless of state the page is in.  Put another way, I think changing the behavior of Esc because onLoad has fired now seems arbitrary to me.

So, I liked the idea someone floated of Shift-Esc being used as the "Full Stop" key.  Shift-Esc doesn't cross into the OS realm of meta key maps, it lets us power users keep using the Esc key (at least in part) to do what we think it should do, and it doesn't arbitrarily kill rich web application's AJAX functions.  Modal parts of the chrome, like the Find bar, could continue to bind to Esc, thus creating a distinction between "Dismiss/Cancel" and "Full Stop".

What I hope happens is the following:
* In Firefox 12 or whenever this fix lands, Esc is no longer bound by FF globally as "Stop" and instead only Shift-Esc is bound for that purpose.

* In exchange for losing the global Esc binding, you dub Shift-Esc as the new "Full Stop" and throw your power users a bone, letting them configure what Full Stop does.  The default behavior for Full Stop would be whatever "Stop" does today, but in the configuration panel you could also add check boxes for "Clear all JavaScript timers", or "Clear all event handler bindings", or even "Debug break"!

* Perhaps keyboards with the dedicated "Stop" button on them could also have that be mapped to the new "Full Stop" as well.

* Upon release, someone pithy writes a snazzy blog post titled "Firefox - Full Stop" that gets posted all over Reddit and Slashdot and HN where all the power users would see it, notifying them of this earth shattering change.  Kerfuffles are detected and hackles are raised over this affront, then the world settles down, your users that give a damn are now trained, and all is well everywhere in the universe till the end of time.  ;)

Thanks for taking this on, Mozilla/Firefox is and always will be my Fav.

Cheers,
Dave Woldrich

    
    

    
  
Hi everyone,

I see a lot and a lot of comments about this issue. What I want to add is that the web is evolving and we stopped having simple websites a long time ago. We started having full blown apps. See all the Chrome Apps for example.

I agree with comment 60 and comment 45. The ESC key is now used a lot from web apps for UI interaction ex. closing modal windows etc. I like the idea of the ESC key to stop network requests and close connection when the page is still loading, but the moment the page is loaded then immediately the ESC is considered to change the behaviour of the UI like closing the Find modal etc. So what that would be different for the behaviour of the ESC key inside the page?

    
    

    
  
The user-doc-needed needs to also remove the Esc listing from https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_miscellaneous

    
    

    
  
an option to stop a gif animation should not be taken out of firefox

i mean there's a difference between telling people to press "esc" 
and "go to this page and install this addon and finish any windows you have open and restart firefox and change the settings to stop a gif". 

it's "intuitive" and "just works" for people

    
    

    
  
I think devs should note that there is disagreement that this was a bug at all or that this trapping/functionality should be given to web apps.  

Even if we assume that web app users expect the ESC key to close modal dialogs, I think we can also safely assume that desktop browser users expect it to stop things.  Including both GIFs and someone's poorly coded XHR.

Additionally the Stop button does almost nothing now, and there is no option for turning off GIF animations, just blocking all images.

Users should not be relegated to an add-on to re-implement a feature that has been around since Netscape.

    
    

    
  
(In reply to mozillabugzilla from comment #64)
> I think devs should note that there is disagreement that this was a bug at
> all or that this trapping/functionality should be given to web apps.  

This is a fair point: the browser emerged out of a lot of legacy design decisions, and I imagine changing some legacy things like what Esc binds to is probably a nightmare proposition to many at Mozilla.  I hope if you do decide to maintain the status quo, you'd continue to allow application developers to suppress the default behavior and supply their own bindings and not take that away from us.

> Even if we assume that web app users expect the ESC key to close modal
> dialogs, I think we can also safely assume that desktop browser users expect
> it to stop things.  Including both GIFs and someone's poorly coded XHR.

I know you say "Desktop Users" above, but your list of what gets stopped seems arbitrary now that we have so many mobile-only users that lack an Esc key altogether.  I don't think average desktop users are told at all what Esc means or does.  So, what is the long-term vision for desktop browsers?  Primarily intended for power users?  I'd wager most desktop users today are not power users and do not know about XHR requests nor which of them are poorly coded.
 
> Additionally the Stop button does almost nothing now, and there is no option
> for turning off GIF animations, just blocking all images.

Are you arguing the stop button's former power should be restored to be that of Esc?  It will flicker from Reload current page to Stop whenever an XHR runs!  I believe Stop is rightly only enabled pre-onLoad, don't change that!  

Consider the motivations that led to the decision to nuke the Stop button to affect a stop pre-onLoad only.  Should those motivations apply to Esc as well?

> Users should not be relegated to an add-on to re-implement a feature that
> has been around since Netscape.

I agree, the behavior (or non-behavior) of Esc is a core feature that should not be relegated to an add-on.  I believe the current behavior of Esc is surprising though, and because of this, I argued for completely unbinding Esc in Comment 60.   I argued instead that a tough-to-accidentally-press key combo (Shift-Esc) should do the same thing that Esc does today.  

To satisfy the power users, I also suggested in Comment 60 that it would be good if the user could configure what this new "full stop" key would do.  For example, I've occasionally wanted a "STOP!" key that would unbind all event handlers, clear timeouts and intervals, as well as kill XHR - making the current page an inert DOM.  I'm unaware of anything that could stop the Javascript show like that today that didn't involve a debugger.  It would be awesome to have control over the page runtime as a user.

    
    

    
  
I disagree that this is a bug. If user presses escape it is because he doesn't want the "XMLHttpRequest and WebSocket" and/or whatever other activity. And anyway, isn't it pointed out here that only 1 or 2 users ever know about ESC key? Then why fix this -- don't waste your time!

    
  
Depends on: 876528

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: