1455101 - Website can capture / (Quick Find bar shortcut) even with Override Keyboard Shortcuts set to Block

Status: RESOLVED WONTFIX

(Toolkit :: Find Toolbar, defect)

Description

[Brian Gomes Bascoy]

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

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
20180418112600

Comment 2

[Neil Deakin]

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.

Comment 3

[Seth W. Klein]

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.

Comment 4

[Brian Gomes Bascoy]

(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!

Comment 5

[Mike de Boer [:mikedeboer]]

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.

Comment 6

[Brian Gomes Bascoy]

(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.

Comment 7

[Will]

(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

[Paul Bone [:pbone] (PTO until 2024-09-08)]

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

[bmarsh]

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.