Autohiding menu bar prevents web content from getting the keyup event for the Alt key
Categories
(Firefox :: Menus, defect, P2)
Tracking
()
People
(Reporter: ivan.kuckir, Unassigned)
Details
(Whiteboard: [lang=c++])
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
Steps to reproduce:
Go to http://jsfiddle.net/p45f44zb/14/ , click into a white area and press various keys. This demo is supposed to show all pressed keyboard keys at every moment in time.
Actual results:
Press Alt. You see ["AltLeft"], which is correct. Release Alt. There is still ["AltLeft"] shown.
Expected results:
Webpages should get a chance to know, whether Alt is pressed or not. My webapp www.Photopea.com performs X, when you press Delete, but it performs Y, when you press Alt+Delete. Many people report a problem, that Y is performed, when they only press Delete (because they used some shortcut with Alt before that).
There are only about 80 000 people a month, who use my program in Firefox. But I still want them to have a good experience. So far, I can't come up with any better solution than recommending them to use a Chromium based browser.
Comment 1•5 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Hi,
I have managed to reproduce this issue on latest FF release 68.0.1, latest Nightly build 70.0a1 (2019-07-28) and Beta 69.0b8 using Windows 7 and Windows 10.
This could be related to the fact that in Firefox the Alt key invoke the menu bar. When menu bar is already displayed, the Alt key will focus it and when the menu bar is not displayed, pressing Alt button will activate it.
Further, I will move this over to a component so developers can take a look over it. I'm not sure if this is the correct component, so if it's not, please feel free to change it to an appropriate one.
Thanks for the report.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Yeah, there is the event if menu is always shown. Something in Firefox UI is eating the event.
Comment 3•5 years ago
|
||
The priority flag is not set for this bug.
:dao, could you have a look please?
For more information, please visit auto_nag documentation.
Reporter | ||
Comment 4•5 years ago
|
||
Webapps in Firefox still can not reliably detect, if the Alt is pressed or not.
My program Photopea is used by thousands of people in Firefox, and I can not provide them any better solution than switching to a Chromium-based browser :(
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Pretty sure this is happening here:
which isn't really frontend.
Neil, can you help? Why does this code need to consume the alt key completely, and is there any way we can avoid consuming it?
(In reply to Ivan Kuckir from comment #4)
Webapps in Firefox still can not reliably detect, if the Alt is pressed or not.
My program Photopea is used by thousands of people in Firefox, and I can not provide them any better solution than switching to a Chromium-based browser :(
Why can't you change the shortcuts away from alt
? Also, why can't you check the event's altKey
property when the key event for the delete
key comes in? Both of these seem like they'd let you workaround the Firefox issue here.
Reporter | ||
Comment 6•5 years ago
|
||
Making a custom version of your website / webapp for each web browser is not the way the web should work.
Many popular desktop programs use specific shortcuts for more than 30 years. Generations of people are used to these shortcuts, and they expect the same shortcuts in a webapp. I would like to provide these shortcuts (and I can provide them in every browser except Firefox).
Comment 7•5 years ago
|
||
(In reply to Ivan Kuckir from comment #6)
Making a custom version of your website / webapp for each web browser is not the way the web should work.
Sure, but my second suggestion (of checking the altKey
property on incoming key events) doesn't require any changes to the user-visible shortcut, or a "custom version" of the site, just a sanity check on an event. I'm not even entirely sure why you track modifier keys separately, instead of only checking them when the combined-with key/mouse event comes in, on that event - AFAIK that's what most other sites do...
Anyway, the reason I hinted at moving away from alt
is that there are still likely to be conflicts with things in the application UI (ie shortcuts you choose may additionally do other things in the app, even if we correctly fire events on the webpage), and in some of those cases, the application UI wins (in both Firefox and Chrome), e.g. shortcuts with ctrl (on Windows/Linux) that involve closing tabs or windows cannot be overridden by the webpage. See also e.g. https://github.com/w3c/uievents/issues/261 for a similar issue that also affects Safari . In other words, I am worried that:
they expect the [desktop] shortcuts in a webapp. I would like to provide these shortcuts (and I can provide them in every browser except Firefox).
is a losing proposition in the long term - not just for Firefox. I've asked about standardization efforts in this space in the past (cf. bug 1612254 ) and unfortunately I am not aware of any.
Reporter | ||
Comment 8•5 years ago
|
||
I think it should be doable on the web, to know what keys are preessed at any moment in time. It is doable in all browsers except of Firefox. My current design works in all browsers, and I think it is not right to change it because of Firefox.
The website wants an action X to happen, when certain keys are pressed. The user wants an action X to happen, when certain keys are pressed. If the browser does not allow the action X to happen, and interprets these keys differently, I think such browser will be replaced eventually. I think, in the long-run, it is better to focus on what users want, and browsers will adapt (or they will be replaced). Regarding the shortcuts consumed by a browser, it will probably be solved by a Keyboard-lock API: https://developer.mozilla.org/en-US/docs/Web/API/Keyboard/lock .
By the way, this issue is not that improtant to me anymore, and I am not reporting new firefox-related issues in my webapp, because I see the usage of Firefox dropping, so it will not be relevant in the future.
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Since the keyup listener in nsMenuBarListener is a non-capturing system event listener on the document, there probably isn't much to stop or prevent, so I think it is probably ok to just remove the event cancellation in nsMenuBarListener::KeyUp.
Also, this is really just a side effect of the way key events are handled in multiprocess mode. With e10s disabled, this bug does not occur.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 10•5 years ago
|
||
Hello, May I work on this? What changes do I need to make?
Comment 11•5 years ago
|
||
(In reply to Jayati Shrivastava from comment #10)
Hello, May I work on this? What changes do I need to make?
It looks like you are assigned to 10 open bugs already. Please complete those bugs or un-assign yourself first before picking up more bugs.
Comment 12•5 years ago
|
||
Can I work on that? Can you point me out where exactly to start investigating
Comment 13•4 years ago
|
||
(In reply to Stefan Yohansson from comment #12)
Can I work on that? Can you point me out where exactly to start investigating
See https://bugzilla.mozilla.org/show_bug.cgi?id=1568130#c5
You can work on this, but I have a general practice of not assigning bugs until patches are attached.
Reporter | ||
Comment 14•4 years ago
|
||
Guys, there are tons of people angry at my me because of you: https://www.reddit.com/r/photopea/comments/gibbdt/layers_copying_itself_for_no_freaking_reason/
When you drag layers in Photopea, you move a layer. But if you hold Alt during it, it duplicates a layer.
Resizing and moving the whole website after pressing Alt really isn't a correct behaviour of a browser. And if you think it is, at least, allow the website to prevent it.
Comment 15•4 years ago
|
||
(In reply to Ivan Kuckir from comment #14)
Guys, there are tons of people angry at my me because of you: https://www.reddit.com/r/photopea/comments/gibbdt/layers_copying_itself_for_no_freaking_reason/
I suggested a workaround for you in comment #5 - check the altKey
property on the event when the key event for the delete key (or, in this case, the mouseup or mouse drag/drop events) come in. This is much more likely to work reliably than your current approach.
For instance, when testing in Chrome (not Firefox) on macOS, in the fiddle from comment #0, if I click in the white frame, press and hold the ctrl key, then move my mouse to chrome's omnibar, click (so the frame with the key listener loses focus), and let go of the control key, the white frame still says ["ControlLeft"]
, even though the key is no longer pressed. In a more realistic case for your app, similar issues would likely occur if dragging images to/from other applications with any modifiers pressed (by accident or otherwise). The same thing happens for shortcut keypresses that go to the OS and unfocus the app (like alt+tab on Windows, cmd-tab on macOS).
You just cannot assume that for every keydown event your app gets for modifier keys, it will get the corresponding keyup event.
We'd be happy to have a patch for the specific alt keyup issue, and if you want to contribute one, will be happy to point you to the code that needs changing (see comment #5 and comment 9) and help with any issues you encounter with building or testing a fix.
Reporter | ||
Comment 16•4 years ago
|
||
My program has a "reset" for all pressed keys, when a website loses focus.
I am aware, that there can be problems in other browsers. I am just saying, that there are more problems in FF than in other browsers.
Your "solution" still does not fix the menu appearing and the resizing of a page, which is not preventable.
Comment 17•4 years ago
|
||
(In reply to Ivan Kuckir from comment #16)
Your "solution" still does not fix the menu appearing and the resizing of a page, which is not preventable.
As I said in comment #7, across browsers, some shortcuts cannot be prevented from taking effect by webpages. Given that the alt key controls primary browser UI in Firefox (the menubar), I don't think we would consider making the menubar showing preventable (ie even if we send the keyup event to content, it would not be able to prevent the menus from working) as long as we keep the menubar. If we were to do so, that would allow websites to break part of the browser UI that users expect to work a certain way and be accessible with the keyboard (so it'd make the browser unusable for visually impaired people, for instance). We could potentially consider having the menubar appear in a way that didn't shift content, but it's not immediately obvious to me how that could work without introducing other problems. We could also consider creating some kind of permission-based APIs (like geolocation, getUserMedia, etc.) to allow webpages to override builtin shortcuts, but we'd likely need to coordinate this with other browsers and as I said previously, unfortunately I'm not aware of activity in this space.
Anyway, if users are bothered by the content shift, as a workaround they could right click the toolbar and show the menubar permanently. Then pressing alt will not do this. Or you could open your tool in a popup window without toolbar features, so there is no menubar - but that is probably not workable for other reasons...
Comment hidden (admin-reviewed) |
Comment 19•4 years ago
|
||
yeah, I came here for the Photopea bug too. Fricking fix this, you are Firefox, you shouldn't have that embarassing bugs.
Comment 20•4 years ago
|
||
is this is still open can i do this,
Comment 21•4 years ago
|
||
Updated•4 years ago
|
Comment 22•4 years ago
|
||
Try push, https://treeherder.mozilla.org/#/jobs?repo=try&revision=c1f57a6ec0b834cba4e16c328dd68e4adde25b5f
I don't see any difference with this patch on my machine, but since I'm running Windows when I press Alt alone the application menu appears which consumes key events. Alt+Delete works as a key using the jsfiddle from comment #0 with and without the patch. Could you test out this patch Andrew and see if it fixes the issue for you? I can update this bug with links to the specific builds once they are available.
Comment 23•4 years ago
|
||
Comment 24•4 years ago
|
||
Backed out for mochitest failures on test_focus_menu.xhtml
Backout link: https://hg.mozilla.org/integration/autoland/rev/b25772c69d2c896cb1a12d267e477b5ddfaf25db
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=313178978&repo=autoland&lineNumber=2610
Comment 25•4 years ago
|
||
Hi Neil, can you help me understand this test failure?
Comment 26•4 years ago
|
||
This is an accessibility test that looks to be checking for the menu active state changes as one cycles through the menus. That means it will be looking for the DOMMenuBarActive, DOMMenuBarInactive, DOMMenuItemActive, DOMMenuItemInactive and DOMMenuInactive events. To start, you could run test pre and post patch and see whether those events line up, and why they might be fire differently.
Comment 27•4 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:jaws, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 28•4 years ago
|
||
I haven't had time to dig in to the test failures recently. I'm going to unassign this bug in the hopes that someone else is able to bring this to completion.
Comment 29•4 years ago
|
||
This was mentioned on hacker news as a top three item for the image editor www.Photopea.com.
Comment 30•4 years ago
|
||
I could imagine that this bug is one of the reasons why other apps like https://boxy-svg.com/app do not support Firefox at all. Desktop-like apps are a thing and there will be more in future. Peoplw using these apps see the website/app as their application while they are working with it. The browser takes the role of the operation system and maybe it should not monopolize the Alt key.
Updated•3 years ago
|
Reporter | ||
Comment 31•3 years ago
|
||
This bug seems to be fixed in the latest Firefox. Are you aware of it? A webpage can prevent a default behaviour of the Alt key in Firefox today. Try it here: http://jsfiddle.net/p45f44zb/14/
Updated•2 years ago
|
Description
•