Closed
Bug 1455101
Opened 6 years ago
Closed 6 years ago
Website can capture / (Quick Find bar shortcut) even with Override Keyboard Shortcuts set to Block
Categories
(Toolkit :: Find Toolbar, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: gomesbascoy, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180327223059 Steps to reproduce: - Visit any GitHub repository. - Open Page Info and then the Permissions tab. - Uncheck "Use Default" for the new "Override Keyboard Shortcuts" permission and select "Block". - Press the / (i.e. slash) key. Actual results: GitHub captures the keydown event and then focus it's own search box. Expected results: GitHub shouldn't be able to override this shortcut: instead, the Quick Find bar should be displayed at the bottom.
Comment 1•6 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 20180418112600
Blocks: 380637
Status: UNCONFIRMED → NEW
Has Regression Range: --- → irrelevant
Has STR: --- → yes
Component: Untriaged → Event Handling
Ever confirmed: true
Flags: needinfo?(enndeakin)
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Summary: New Override Keyboard Shortcuts permission doesn't work as expected → Website can capture / (Quick Find bar shortcut) even with Override Keyboard Shortcuts set to Block
Comment 2•6 years ago
|
||
We don't block printable characters as they need to be able to be entered on the page, only shortcut keys get blocked. You can use Ctrl/Cmd+F for find at least.
Flags: needinfo?(enndeakin)
Comment 3•6 years ago
|
||
Slash and Quick Find are much more convenient than Ctrl/Cmd+F. I'm frustrated continually by their lack when using things besides Firefox, less, vim, and similar. If it's impossible to make slash and Quick Find work due to the design of the web, that's a sad but sufficient answer. Pointing out that Ctrl/Cmd+F are available is not a sufficient answer for the reason just stated.
Reporter | ||
Comment 4•6 years ago
|
||
(In reply to Neil Deakin from comment #2) > We don't block printable characters as they need to be able to be entered on > the page, only shortcut keys get blocked. You can use Ctrl/Cmd+F for find at > least. How so? slash displays the "Quick find" bar. It's extremely counterintuitive that a website can still hijack this functionally when the user explicitly configured the browser to not allow this kind of behavior. The fact that the slash key prints a slash character when some sort of text box in the DOM is focused is unrelated to this particular issue. Thanks!
Updated•6 years ago
|
Component: Event Handling → Find Toolbar
Product: Core → Toolkit
Comment 5•6 years ago
|
||
This is by design and very hard to implement differently. Since this has worked like this from the very beginning and there's no sign that QuickFind and its `/` and `'` shortcuts will be removed any time soon (if ever). Therefore I think it's appropriate to close this, since there's nothing actionable left.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 6•6 years ago
|
||
(In reply to Mike de Boer [:mikedeboer] from comment #5) > This is by design and very hard to implement differently. Since this has > worked like this from the very beginning and there's no sign that QuickFind > and its `/` and `'` shortcuts will be removed any time soon (if ever). > Therefore I think it's appropriate to close this, since there's nothing > actionable left. By design websites can disable user agents functionalities? :-/ sorry but I really don't understand the reasoning to close this ticket: - There is only one way to access QuickFind, which is using its shortcuts. - Because JavaScript have the capability to intercept keystrokes, Firefox just added a fantastic new permission control called "Override Keyboard Shortcuts". - In principle, users that don't want their shortcuts being hijacked by websites they frequently use (an horrendous yet pretty common modern anti-pattern) should now be able to block this. - Unfortunately, in reality that's still not the case... websites still have more power than the user itself over its own user agent, since they can completely block part of its functionality. I understand that this seems to be a super minor issue, but some people really use QuickFind. Thank you.
(In reply to Mike de Boer [:mikedeboer] from comment #5) > there's nothing actionable left. The action seems clear to me: '/' is clearly a keyboard shortcut, so when keyboard shortcut overrides are disabled, it should behave the way it does on pages without javascript regardless of the javascript on any given page. In particular, when an input field is focused, it should insert a forward slash; otherwise, it should bring up and focus the quick find bar. Incidentally, the preference does capture backspace even in text boxes (which is clearly wrong), so the functionality needs to be revamped in such a way that supporting slash becomes trivial regardless. It is a major frustration when pages override this functionality, and I was looking forward to being able to override them back. The fact that the fix for 380637 is incomplete is a significant drawback.
Comment 9•6 years ago
|
||
I agree, '/' functions as a shortcut when a text box isn't focused. Therefore it's a shortcut and must not be overridden. And yeah, when you block github from getting shortcut keys for some reason backspace breaks. So: 1) '/' should always do quick find when a text box is not focused. 2) What's up with backspace? Maybe some broken JS on github? 3) This permission should be more granular, allowing me to block github's access to '/' and not Backspace. Can we reopen this bug please?
Comment 10•3 years ago
|
||
Bug needs to be re-opened as more and more sites are hijacking "/" . GitHub and Fandom for example. Also, sharepoint.com when editing a document overrides CTRL-SHIFT-1 which would open normally container 1.
Please re-open this bug to be fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•