The 'f' key shortcut used to activate the filter field breaks Alt+f (file-menu key combo)

NEW
Unassigned

Status

P3
normal
3 years ago
8 months ago

People

(Reporter: dholbert, Unassigned)

Tracking

Details

(URL)

(Reporter)

Description

3 years ago
STR:
 1. Visit any site, e.g. https://www.mozilla.org/en-US/ , and hit "Alt+f".
     --> Browser's File menu opens. (At least, it does for me, on Linux.)

 2. Now, visit https://treeherder.mozilla.org/ and hit Alt+f

ACTUAL RESULTS:
Treeherder intercepts the key combination and activates its "Filter" field. (This is also what happens if I just press "f".)

EXPECTED RESULTS:
Browser's File menu should open.


STR #2:
 1. Visit https://treeherder.mozilla.org/ and press Ctrl+F.
  --> Find-in-page opens.
 2. Hit "Esc" key.

ACTUAL RESULTS: TreeHerder's "filter" field is active once I leave the browser's find-in-page UI.

EXPECTED RESULTS: "filter" shouldn't be activated by Ctrl+f, Esc.

Bottom line:
============
I think Treeherder is just listening for "f" keypresses, and not paying attention to whether there were modifier keys along with the "f". It should check if there were modifier keys, and ignore any such keypresses. Ctrl+f / Alt+f should be considered different signals from "f".
(Reporter)

Updated

3 years ago
Summary: Treeherder intercepts access-key for browser's File menu, Alt+f, and activates its own filter field instead → Treeherder aggressively listens for "f" keypresses to activate its "filter" field, which breaks Alt+f (file-menu key combo) & gives weird behavior after Ctrl+f (find-in-page)
(Reporter)

Comment 1

3 years ago
(Sorry, disregard mentions of Ctrl+f / find-in-page & my "STR #2" above. The ACTUAL RESULTS there only happen if the filter field was focused before Find-in-page was activated -- and that makes sense.

So, this is only a problem with Alt+f, AFAICT.)
Summary: Treeherder aggressively listens for "f" keypresses to activate its "filter" field, which breaks Alt+f (file-menu key combo) & gives weird behavior after Ctrl+f (find-in-page) → Treeherder aggressively listens for "f" keypresses to activate its "filter" field, which breaks Alt+f (file-menu key combo)

Updated

3 years ago
Blocks: 1133545
Summary: Treeherder aggressively listens for "f" keypresses to activate its "filter" field, which breaks Alt+f (file-menu key combo) → The 'f' key shortcut used to activate the filter field breaks Alt+f (file-menu key combo)
I can repro this also on Windows using an old PC keyboard with a real Alt key. If I use an Apple keyboard (where 'alt' is available via shift+option) I can't, the browser's File menu comes up fine. Similarly on OSX, Cmd/Meta, Option, Option/Alt appear to be fine and are ignored and only 'f' opens the quick filter.
Oh, interesting. On Google Chrome, where Alt+f opens their 'hamburger' control settings, it works perfectly when sitting on https://treeherder.mozilla.org
https://support.google.com/chrome/answer/157179?hl=en > Google Chrome Feature Shortcuts > Windows,Linux

Daniel can you try that to confirm also?
Flags: needinfo?(dholbert)
(Reporter)

Comment 4

3 years ago
Yup, I can confirm that -- this isn't reproducible in Chrome.

(That might just be because Chrome is more vigilant than Firefox is about preventing web pages from stealing its keybindings. At least, bug 380637 is marked "parity-chrome")
Flags: needinfo?(dholbert)
(Reporter)

Comment 5

3 years ago
(Yeah, bug 1052569 comment 0 says "Other browsers like Chrome do not allow web pages to override [certain reserved keyboard shortcuts]".  A web page tested mainly in Chrome may accidentally break these shortcuts in Firefox without the developer realizing it.  This seems to be happening regularly in the wild.

So, comparison to Chrome here isn't really useful, other than as further confirmation that we should try to do something about bug 380637 / bug 1052569.)
Ok thanks Daniel. I'll defer to someone on the treeherder team with access to a decent development Linux/Win machine to investigate a fix. The PC I repro'd it on is >10yr old and barely runs :) If you can indicate how severe you feel the bug is, we can set a Priority relative to our other bugs in the queue.
I can probably take this.
Assignee: nobody → wkocher
Fun. Testing this in release builds of Firefox, I can reproduce comment 0's problem. It doesn't reproduce for me against Nightly... (Maybe some e10s issue with keyboard events?)
(Reporter)

Comment 9

3 years ago
Yup, it seems this only reproduces if e10s is disabled. (Just double-checked locally w/ nightly + fresh profile.)
That would be consistent with what I saw reproducing it on my old PC. I just had release installed there, but not Nightly.

Updated

3 years ago
Priority: -- → P2

Updated

3 years ago
Priority: P2 → P3

Updated

a year ago
Component: Treeherder → Treeherder: Frontend
Assignee: kwierso → nobody
You need to log in before you can comment on or make changes to this bug.