Window does not respond to keyboard shortcuts when a plugin has focus

RESOLVED INACTIVE

Status

()

Core
Plug-ins
--
major
RESOLVED INACTIVE
3 years ago
9 hours ago

People

(Reporter: mchang, Unassigned)

Tracking

({regression})

Trunk
Unspecified
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox40 affected)

Details

(Reporter)

Description

3 years ago
Sometimes, usually after I've been browsing for a while, keyboard shortcuts don't work. For example, using command-Q to quit doesn't actually quit the browser and I have to manually go to Nightly -> Quit Nightly. 

This also extends to trackpad gestures. Swiping left to go back sometimes does not respond and I can't go back at all unless I manually click the back button. This seems to have happened within the past week or so.
(Reporter)

Updated

3 years ago
Severity: normal → major

Updated

3 years ago
tracking-e10s: --- → ?
(Reporter)

Comment 1

3 years ago
Was finally able to find a site that reproduces frequently. STR on a retina macbook pro

1) Go to hbogo.com
2) Login
3) Play any video, then full screen
4) Come out of full screen
5) Notice that Nightly is unresponsive to any keyboard shortcuts such as command-n for new window or command-q to quit firefox.
Keywords: regression
Summary: [e10s] Window does not respond to keyboard shortcuts → Window does not respond to keyboard shortcuts
(Reporter)

Comment 2

3 years ago
Even better STR:

1) Go to hbogo.com
2) Click out of any login window pop ups
3) Try to play any content, it'll ask you to sign up. Just click the box away.
4) Notice no keyboard shortcuts will work.

Updated

3 years ago
OS: Unspecified → Mac OS X
Flags: needinfo?(davidp99)
Tracked issue to mWantReplyFromContentProcess, set by the nsXBLWindowKeyHandler
Flags: needinfo?(davidp99)
tracking-e10s: ? → m7+
Update:

Initial guess was wrong.  This is a plugin focus issue.  It actually happens with all flash plugins.  It is not e10s-specific, not new and is not related to the patch from Bug 1060643 as I initially thought... I have verified in a non-e10s window from the 3/22 nightly build (the oldest I have handy).

Another STR:
* Open an e10s window
* Go to a random swf on fastswf.com -- e.g. http://www.fastswf.com/23fV5-c 
* click the swf (like in the HBO-GO case, everything works fine until this happens)
* Type / or Command-F to open the search bar

Expected result:
The search bar opens and takes focus

Actual result:
nothing

:felipe mentioned in IRC that we specially handle some keys but it sounds like even those don't work.  Some other keys that I've tried (none worked in e10s or non-e10s): Command-T (new tab) and Command-Q (quit).

I'm changing the component to plugins and dropping this from e10s tracking.  And the usual: NIing smichaud so he knows this exists and can decide what the plan is for it.
tracking-e10s: m7+ → ---
Component: Keyboard: Navigation → Plug-ins
Flags: needinfo?(smichaud)
Extra note: I dont think Flash is supposed to be able to swallow some of those commands in any case but, just in case we suspect this is intended behavior, note that I get the Expected Result in Safari.
This is a very old bug, that has existed in various forms since the dawn of time:  If a plugin has the keyboard focus, it tends to steal cmd-key events from the browser.

It's gotten much worse recently (on the Mac), probably because of bug 1092630.
Flags: needinfo?(smichaud)
Notice that the menu still flashes even when the cmd-key combination has no effect.
See bug 78414 for endless (and not very helpful) discussion of the general problem.

At some point, someone needs to review all of keyboard-shortcut handling code -- at least on the Mac, and perhaps on all platforms.  On the Mac, I'll bet a lot of it was either removed or broken by bug 1092630.

I'm almost certainly not going to get to this before I retire, sometime later this year :-)
> all of keyboard-shortcut handling code

With regard to plugins, that is.

As part of this discussion, we'll need to decide what kinds of keyboard shortcuts need to be reserved by the browser, and which can be passed to plugins.  Maybe we could first give a keyboard shortcut to the browser, then pass it to a plugin if the browser didn't handle it.  Maybe we're already doing this (or trying to) in various parts of the tree ... but if so it's mostly not working.
Summary: Window does not respond to keyboard shortcuts → Window does not respond to keyboard shortcuts when a plugin has focus

Comment 10

9 hours ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 9 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.