Shift+ESC should stop XHR, WebSocket, animations even when the stop button is disabled




Keyboard Navigation
5 years ago
5 years ago


(Reporter: Florian Bender, Unassigned)



20 Branch

Firefox Tracking Flags





5 years ago
Bug 614304 changed the behaviour of ESC. The previous behaviour (i. e. abort XHR and WS, any network connection) should come back with typing Shift+ESC. This behaviour is wanted by power-users and is useful in environments with restrained or expensive bandwith, among other reasons (e. g. during development). I also believe this feature should be baked into Firefox rather than being served by addon which means even more hassle and bandwith to waste. Plus, it's a no-brainer and really straightforward to implement (judging by the patch in Bug 614304).


5 years ago
tracking-firefox20: --- → ?
Depends on: 614304
Severity: normal → enhancement
Component: Untriaged → Keyboard Navigation
Ever confirmed: true
Summary: Shift+ESC should abort XHR and WS → Shift+ESC should stop XHR, WebSocket, animations even when the stop button is disabled

Comment 1

5 years ago
I'm not so sure about stopping animations. However, if this was the original, pre-20 behaviour, let's do it.


5 years ago
Keywords: dev-doc-needed, user-doc-needed
Keywords: dev-doc-needed, user-doc-needed
I think this would better be implemented as an add-on. It's edge-case functionality.

Comment 3

5 years ago
Nope, not an edge case at all (if you exclude every broadband-always-on user). Plus it's helpful for devs, too. And it's such a small patch, it barely justifies being packaged as a multi-kB addon. But I'm repeating myself …
The size of the user base that could potentially benefit is not really relevant - what matters is the size of the user base that both a) could potentially benefit and b) would actually discover it. The set of people in b) would be incredibly small, but it may still be a useful mitigation for people who knew about the pre-bug 614304 behavior (again a very small minority of users, I assert).

The bar for implementing features in Firefox is higher than "just a small patch". A "multi-KB add-on" may offend your sense of efficiency, but it does not represent a practical problem for someone who'd really want this functionality. I ended up just implementing this, since it was so easy: (pending review)
Last Resolved: 5 years ago
tracking-firefox20: ? → -
Resolution: --- → WONTFIX
FWIW: the XPI is 1.8KB :)

Comment 6

5 years ago

However, I still don't see it. It's a matter of adding a one-liner to the codebase so everybody can use it right away, vs. creating an addon which has to be maintained, and installed if anybody wants to use it. This is a lot of code, CPU cycles and worktime spent which could have been solved with a lot less effort for everyone. Yes, a lot of small things like this could blow up the codebase, but it'd be foolish to not include such small things which do not have a measurable cost attached to it, that enhance the experience for (at least) some users. 

Either way, thanks again for providing at least an acceptable solution.
Adding every "single line" that someone might request to Firefox means we end up with a humongous testing matrix and paralysis any time we need to change anything. There's a cost to having a lot of little-known functionality hanging around that's not be obvious until you're actually tasked with maintaining a code base like this one.

The bar is much higher than "some users".


5 years ago
Keywords: ux-control

Comment 8

5 years ago
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
You need to log in before you can comment on or make changes to this bug.