Open Bug 1490665 Opened 7 years ago Updated 3 years ago

Come up with a permissions system for users to allow websites to override browser shortcuts

Categories

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

62 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: ivan.kuckir, Unassigned)

References

()

Details

(Keywords: testcase)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180830143136 Steps to reproduce: Go to http://jsfiddle.net/p45f44zb/14/ and click into the white area. Press some keys. The JS is preventing the default behaviour of every shortcut. Press Ctrl+T Actual results: Firefox opens a new tab. Expected results: The default behaviour should have been prevented. I am making the photo editor www.Photopea.com, and Ctrl+T, Ctrl+N are important shortcuts, that users know from native editors. It is a shame we can not use them on the web.
I take it this is Wontfix, given that bug 1052569 aims to do the opposite.
Component: Untriaged → Event Handling
Flags: needinfo?(gijskruitbosch+bugs)
Keywords: testcase
Product: Firefox → Core
Could you re-evaluate your decissions from the past? Today, we use the web to make advanced programs. This is one of the main features, that handicaps web apps, and makes native apps superior. If users don't like, that the website "prevents" their Ctrl+T browser shortcut, they will find a way to let the author know (e.g. by not visiting the website anymore). In a long run, default behaviour would be prevented only in cases, where it is really needed and expected by the user.
(In reply to Gingerbread Man from comment #1) > I take it this is Wontfix, given that bug 1052569 aims to do the opposite. Specifically, the original bug as filed is a dupe of bug 1291706 and WONTFIX. (In reply to Ivan Kuckir from comment #2) > Could you re-evaluate your decissions from the past? > > Today, we use the web to make advanced programs. This is one of the main > features, that handicaps web apps, and makes native apps superior. > > If users don't like, that the website "prevents" their Ctrl+T browser > shortcut, they will find a way to let the author know (e.g. by not visiting > the website anymore). In a long run, default behaviour would be prevented > only in cases, where it is really needed and expected by the user. The browser's first responsibility is to protect the user and act as the user's agent. So just allowing any website to hijack all the browser's shortcuts isn't really workable; it enables all kinds of ransomware-through-the-web attacks (have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=eviltraps if you don't believe me). So allowing this by default is a non-starter. The only thing I can think of here is to give users a per-domain opt-out, and websites a way to essentially request permission to override these shortcuts. But that'd have to be coordinated for spec work with other browsers, because they implement similar restrictions. I'll leave it for the folks in Core::Event Handling to work out how that would go, or if there's prior art in that space already, because I don't know.
Flags: needinfo?(gijskruitbosch+bugs)
Summary: Let websites implement Ctrl+T and other shortcuts → Come up with a permissions system for users to allow websites to override browser shortcuts
You are referring to a 11 years old case, and I hope browsers went a long path of development since that days. I noticed, that there are only three shortcuts, that can not be prevented in current browsers: Ctrl+T, Ctrl+N and Ctrl+W. These shortcuts have their analogy at the top part of the browser UI, so there will still be a way how to do it. The only problem I see is in the Fullscreen mode, or in the Mouse Lock mode. But those modes can always be escaped (it should be guaranteed without any relation to this case). Yes, there can be some people surprised, that their shortcut does not work, so they would have to "click it" instead. But there will be much more people amazed and thankful, that their favourite shortcut from native apps works in a web app. People spend 99% of their web time on 5-6 websites, which they trust. We should focus on improving the experience of using these 99% websites, instead of worrying about tiny inconveniences of 1% websites, which occur very rarely.
(In reply to Ivan Kuckir from comment #4) > You are referring to a 11 years old case No, I'm referring to all the open dependencies of that bug, many of which were filed in the last weeks/months. > and I hope browsers went a long path of development since that days. Yes, and one of the ways in which we addressed pages' ability to trap users was to reserve a few core shortcuts that should always work. (and also, any of the bugs on that tracker that are kept open likely still exist, ie haven't been fixed) > I noticed, that there are only three shortcuts, that can not be prevented in > current browsers: Ctrl+T, Ctrl+N and Ctrl+W. These shortcuts have their > analogy at the top part of the browser UI, so there will still be a way how > to do it. Not if the page also detects the mouse leaving the page and does other nasty things based on that... And if you argue "well, you should fix that" - then why is it that you think we'd need to address that, but not address shortcut abuse? It'd be a double standard if we prefer web apps in one case but not another... > The only problem I see is in the Fullscreen mode, or in the Mouse Lock mode. > But those modes can always be escaped (it should be guaranteed without any > relation to this case). Why "without any relation"? Right now, ctrl-w is one of the guaranteed ways that can be done. > Yes, there can be some people surprised, that their shortcut does not work, > so they would have to "click it" instead. But there will be much more people > amazed and thankful, that their favourite shortcut from native apps works in > a web app. > > People spend 99% of their web time on 5-6 websites, which they trust. We > should focus on improving the experience of using these 99% websites, > instead of worrying about tiny inconveniences of 1% websites, which occur > very rarely. You cite no sources for these numbers, or the idea that more people will appreciate websites being able to override things vs. the opposite. Please consider: https://blog.mozilla.org/nnethercote/2014/01/02/yeinu-your-experience-is-not-universal/ https://www.gijsk.com/blog/2015/02/yeinu-your-experience-is-not-universal-continued/ In any case, even if you were completely right, if there were a permissions prompt, users could opt-in to (the minority of the) 5-6 websites - so likely 1 or 2 - using the permissions prompt, without compromising their safety or browser functionality on other untrusted pages that they end up on through e.g. malvertising.
Tom may want to weigh in here.
Flags: needinfo?(tom)
Priority: -- → P3
No strong feedback beyond what Gijs said. As a platform, we really want to avoid permission prompts; but overriding what amounts to the 'Secure Attention Keys' of the web is pretty fraught with danger.
Flags: needinfo?(tom)
Here is a corresponding issue at Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=119881 , maybe you could cooperate somehow? My app needs only Ctrl+N and Ctrl+T. A new window and a new tab can be opened through the browser UI, so I do not see any danger if some webpage prevents the default behaviour of these shortcuts without the user expecting it. Ctrl+O and Ctrl+S can already be prevented in all browsers, so I don't see any big difference. I do not see tons of users complaining to browser makers for letting webapps override these shortcuts. If it was up to me, I would let webapps override all keyboard shortcuts, when the UI is accessible. And when it is not (during Fullscreen or Pointer Lock), I would leave the Escape key "unpreventable", so pressing Escape would make the UI accessible again.
Component: Event Handling → User events and focus handling

As more and more applications are ported to Web 2.0, it's ever more important to allow users to retain the shortcuts they are familiar with.

As a developer-focused example, consider Amazon's open source Cloud9 IDE. It's a great product, that opens a full IDE in a browser window, including multiple editor tabs, a sidebar with open files, integrated terminal tabs, and so on, all running on a remote server.

Unfortunately, Firefox still keeps many shortcuts for itself (Ctrl-N, Ctrl-T, Ctrl-W...) and does not provide a permission system where I can grant full control of the keyboard to that specific website.

As a result, every time I'm using the integrated terminal, I keep hitting Ctrl-W (delete word to the left) and accidentally close the entire IDE. The same goes for the editor tabs, I keep hitting Ctrl-W by mistake when I want to close them, because that's what I've been doing every single day for decades on all other IDEs and editors.

Luckily in this case, Cloud9 IDE has a preference to enable the beforeunload dialog "This page is asking you to confirm that you want to leave. Stay on page / Leave page" so that I don't have to reload the entire app every time I hit it by mistake. But it's still annoying.

Can we please raise the priority of this bug?

With the removal of SSB (Single Side Browser) from Firefox 86, this feature is essential for web-apps such as Cloud9, Code Server or Theia, that make extensive use of shortcuts that conflict with Firefox shortcuts.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.