- Env Windows 10. (I cannot reproduce this on macOS) - Step 1. open data:text/html,<input> 2. input "aaaabbbb" in <input> element 3. select "bbbb" 4. click [cut] menu in hamburger button. It works well. 5. input "cccc" 6. select all text ("aaaacccc") 7. click [cut] menu in hamburger button - Result "aaaacccc" isn't removed and it is copied to clipboard. If using keyboard shortcut or [edit] - [cut] in windows's menu bar, it works fine. - Excepted result "aaaacccc" is removed and it is copied to clipboard. Since mozregression cannot found m-i or autoland build, I cannot find narrow regression range. https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=035c25bef7b5e4175006e63eff10c61c2eef73f1&tochange=fe809f57bf2287bb937c3422ed03a63740b3448b

(In reply to Makoto Kato [:m_kato] from comment #0) > - Env > Windows 10. (I cannot reproduce this on macOS) I bet this reproduces on Linux as well, macOS is the odd one out in how it enables edit controls. > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=035c25bef7b5e4175006e63eff10c61c2eef73f1&tochange=fe80 > 9f57bf2287bb937c3422ed03a63740b3448b I'm a bit confused - this range contains the initial turning on of photon UI. Did the cut button in the old (pre-photon) hamburger menu not have this bug? Also, can you reproduce this if you put edit controls in the toolbar? Under the hood, the button is supposed to just mirror the cut/copy/paste editor commands, so I'm not sure why this would be any more/less broken than the context menu or toplevel menu or the customizable buttons in the toolbar. :-(

(In reply to :Gijs (he/him) from comment #1) > I'm a bit confused - this range contains the initial turning on of photon > UI. Did the cut button in the old (pre-photon) hamburger menu not have this > bug? I guess that this occurs by photon's hamburger menu. It seems to lost focus during cut command from hamburger menu. > Also, can you reproduce this if you put edit controls in the toolbar? No. This doesn't occur when edit menu is in toolbar.

At step 5, when I start typing, something is setting tabindex="0" on the cut button which makes it focusable. The tabindex is set anytime I type into a field while the popup is open. Presumably some event handler related to the panel isn't checking what is focused.

(In reply to Neil Deakin from comment #3) > At step 5, when I start typing, something is setting tabindex="0" on the cut > button which makes it focusable. The tabindex is set anytime I type into a > field while the popup is open. > > Presumably some event handler related to the panel isn't checking what is > focused. Keyboard navigation in the panel is implemented in a way that moves focus. For that to work, the items have to be focusable. This is why the tabindex is being set. I'm pretty confused about why typing even works with the panel open. If I open the context menu, I can't type - any matching access keys activate those menuitems, any other keys are completely ignored. I don't know what does that and why it doesn't happen for the hamburger panel while it's open... Neil? Making the items focusable doesn't really make sense for the clipboard buttons, because once they're focused whatever was focused before isn't anymore. The short way of fixing this is to just make an exception for those buttons (e.g. by setting tabindex=-1 on them in the markup), though it'll be a bit confusing if you keyboard navigate through them as we'll just skip over them. The longer way would be to rearchitect the keyboard navigation and use something other than actual focus to keep track of the selected element, but that's obviously a bunch more work (and fundamentally, doesn't really address what should happen here if the user uses e.g. arrow keys or home/end, which the keyboard navigation supports and will act on, though the user might expect it to go to the input). Though, tbh, I'm also confused why the hamburger menu doesn't close after using the cut/copy/paste buttons... The keyboard nav is set up on the assumption that we don't need If it did, this problem would go away... Mike, do you remember if that was a deliberate decision? I don't see anything in bug 1354108...

(In reply to :Gijs (he/him) from comment #4) > Keyboard navigation in the panel is implemented in a way that moves focus. > For that to work, the items have to be focusable. This is why the tabindex > is being set. I'm pretty confused about why typing even works with the panel > open. If I open the context menu, I can't type - any matching access keys > activate those menuitems, any other keys are completely ignored. I don't > know what does that and why it doesn't happen for the hamburger panel while > it's open... Neil? Panels only handle the Escape key, whereas menus handle and cancel most key events. If you're not expecting the user to be able to type anything while the panel is open, yet leave the input field focused, you would need to cancel any necessary key events.

(In reply to :Gijs (he/him) from comment #4) > Though, tbh, I'm also confused why the hamburger menu doesn't close after > using the cut/copy/paste buttons... The keyboard nav is set up on the > assumption that we don't need If it did, this problem would go away... Mike, > do you remember if that was a deliberate decision? I don't see anything in > bug 1354108... I think that back then I noticed that the actions wouldn't work when the popup auto-closed. Thus I set closemenu="none" on the whole toolbaritem.