Closed Bug 1682340 Opened 4 years ago Closed 4 years ago

Reader Mode activates erroneously when trying to activate the Search History in the Console's multi-line editor mode

Categories

(DevTools :: Console, defect)

defect

Tracking

(firefox86 fixed)

RESOLVED FIXED
86 Branch
Tracking Status
firefox86 --- fixed

People

(Reporter: itiel_yn8, Assigned: nchevobbe)

Details

Attachments

(1 file)

STR:

  1. Be on this bugzilla ticket
  2. Ctrl+Shift+K to open the console
  3. Enable the multi-line editor mode
  4. Hit F9 to enter the Search History function there

AR:
The webpage enters reader mode, and the Search History activates, both at the same time.

ER:
Assumingly don't enter reader mode, but I'm not sure what would be the criteria for not enabling it...

So, funny thing, I don't get offered reader mode on this bug at time of writing (I expect it depends on the amount of text, so this might change with this comment and/or later). Also, on macOS the shortcut for history appears to be Ctrl+R, and the reader mode shortcut is command+opt+R on macOS, so there's no conflict. But I can see how this would be an issue on Windows/Linux, where the shortcuts are presumably the same...

I think devtools already calls preventDefault() at https://searchfox.org/mozilla-central/rev/8d722de75886d6bffc116772a1db8854e34ee6a7/devtools/client/webconsole/components/Input/ReverseSearchInput.js#116-118 . This is done from the keydown handler. AFAICT the reader mode shortcut (implemented using a <key> element) gets invoked before devtools even runs.

Neil, do you know why, in this case, XUL's <key> element handling happens before devtools, even if focus is in the input box there? Is there anything we can do to fix this?

Flags: needinfo?(enndeakin)

Hey Mossop, I know you did some <key> stuff back in the day for de-XBL'ing... is this something that sounds kinda familiar? In particular, why does the <key> event on a window handle the key events before DevTools, even if input focus is on the devtools and they preventDefault on it? (The <key> looks like it tries to handle the event at the bubbling phase).

Flags: needinfo?(dtownsend)
Severity: -- → S4
Priority: -- → P3

(To be clear, I can reproduce this on Windows.)

The problem is that devtools aren't calling preventDefault on the event. The handler that Gijs points to is the one on the Search History input itself and that does preventDefault and indeed reader mode doesn't open if you press F9 while that is focused. The handler for the console editor panel though is this one: https://searchfox.org/mozilla-central/source/devtools/client/webconsole/components/App.js#137-148

Flags: needinfo?(dtownsend)
Flags: needinfo?(enndeakin)

Good eye, thanks Mossop!

Component: Reader Mode → Console
Product: Toolkit → DevTools
Priority: P3 → --

Thanks Gijs and Dave for the investigation, I'll fix that

Assignee: nobody → nchevobbe
Status: NEW → ASSIGNED

We weren't calling preventDefault on the event handler, which was
allowing the browser to consume it, and toggle reader mode on windows,
which shares the same keyboard shortcut (F9).
A test is added to ensure we don't regress this (the test is failing without
the fix).

Pushed by nchevobbe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/65d5af50131e [devtools] Prevent triggering Reader Mode with reverse search keyboard shortcut on Windows. r=bomsy.
Pushed by nchevobbe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7deb43b486c1 [devtools] Prevent triggering Reader Mode with reverse search keyboard shortcut on Windows. r=bomsy.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Flags: needinfo?(nchevobbe)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: