Web Developer Tools Hijacking Shortcut Keys




Developer Tools: Framework
2 years ago
2 years ago


(Reporter: Canis_Enigmas, Unassigned)


48 Branch

Firefox Tracking Flags

(Not tracked)




2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

Use one of the following extensions below to configure and override shortcut keys that are being used by Web Developer tools.

Example: I use 'Ctrl-Shift-Q' set to "Close Window" which is the default shortcut keys for "Network" tab of Web Developer. I have tried disabling and setting this to my own key 'Alt-F7' 

Restart the browser


Actual results:

Web Developer Tools hijacks the shortcut keys and resets it to its own settings

Now there are duplicate 'Ctrl-Shift-Q' shortcut key entries in the configuration settings and Web Developer tools takes precedence in execution and prevents my configured action from running. 

Expected results:

Web Developer tools should not default shortcut keys and remain as configured by these extensions.


2 years ago
QA Whiteboard: [bugday-20160905]
Component: Untriaged → Developer Tools
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0

I have tested this issue on Windows 10 x64 with the latest Firefox release (48.0.2) and the latest Nightly (51.0a1-20160904030201) and managed to reproduce it.
After previously installing "Dorando keyconfig 2016.2" add-on and configuring the following shortcuts: 'Ctrl-Shift-Q' set to "Close Window" and 'Alt-F7' for "Network" tab of "Web Developer", after restarting the browser,  you can observe in the add-on options panel the 'Ctrl-Shift-Q' shortcut key entries are duplicated and the 'Alt-F7' shortcut doesn't work anymore.
Ever confirmed: true
:ochameau, is this related to your shortcuts work?
Component: Developer Tools → Developer Tools: Framework
Flags: needinfo?(poirot.alex)
Priority: -- → P3
Ctrl+Shift+Q is still using XUL. It hasn't been refactored to use the key shortcut module which would obviously cause such issue with addons playing with <xul:key> elements.

I imagine it is more related to bug 1248603, where we add these keys dynamically, may be after the dorando addon does its key hijack. May be the addon can delay its key insertion a bit and take the precedence. But on the long run, these keys are also meant to use the new key shortcut module which will break this addon again and I'm not sure there is any simple way to accomodate? The easiest may be able to allow custom key mapping for devtools...
Flags: needinfo?(poirot.alex)
You need to log in before you can comment on or make changes to this bug.