Cannot use firefox keyboard shortcuts when flash object is selected

Bug #263435 reported by komputes on 2008-08-31
108
This bug affects 20 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
High
firefox-3.0 (Ubuntu)
Undecided
Unassigned
flashplugin-nonfree (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: flashplugin-nonfree

Firefox cannot close tab (using Ctrl-w) or Quit (using Ctrl-q) or switch to next tab (using Ctrl-Tab) when flash content is selected on page.

Steps to reproduce:
1) Open a new Tab
2) Go to a website with flash content (in this case youtube.com)
3) Selected the flash content by clicking on it (in this case click on play)
4) While the content plays, press a keyboard shortcut (in this case Ctrl-w to close the tab)

Result: The shortcut is not registered by firefox, the tab remains open
Expectation: The shortcut should be registered by firefox, the tab should close

A good way of knowing that "selecting the flash content" is at the root of the problem: if you select a part of the page that is not flash content (in this case empty white space at the right or the left of the video) followed by Ctrl-W, the tab closes.

Version Information:
Ubuntu Hardy (2.6.24-19-generic)
firefox 3.0.1+build1+nobinonly-0ubuntu0.8.04.3
flashplugin-nonfree 9.0.124.0ubuntu2

Macromedia Bug 67613

I wonder if something to this effect would work: if any of the "modifier" keys
are down, send that event to Moz instead of the plugin on Mac only.

Keys should should work, especially after closing window. Taking bug.

Okay, looked closer at this. There are two bugs here. First, "lost focus" wasn't
working. Typo, should be using NS_CONTENT_BLUR instead of NS_LOSTFOCUS. Need
to double check that it won't cause regressions on other platforms, but once
that was fixed, one can click outside the plugin content area and then command
keys work as expected. In fact, you could scroll the page with the keyboard and
other key events seem to work.

The other problem is that the plugin was consuming all key events. Perhaps Peter
G. from Macromedia knows if Shockwave returns consume status on keys like this
or if Nav was responsible for filtering them out.

Even after returning nsEventStatus_eIgnore from the DOM key event in
nsObjectFrame.cpp if a "meta" key was down, it still looked like my event was
consumed. Probably need to set some breakpoints in the EventStateManager.
Pinkerton or Saari, do you have any tips on debugging this on the Mac? I wonder
if there is a way to process shortcut keys before sending the event to the DOM.

Moving to m0.9.2

Recommend mozilla0.9.3 for this. If you feel this is very urgent, please
re-triage.

In , Shrir (shrir) wrote :

*** Bug 94900 has been marked as a duplicate of this bug. ***

Plataform and OS should be changed to ALL, it happens on Win98 too, see bug 94900.

Keywords should be changed to: 4xp, shockwave, top100

Please, could any "sufficiently empowered user" do so? Thanks :-)

Note: all this changes are based on Bug 94900

Marcos.

Refining the bug report, and giving the current status.

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010810
BuildID: 081003

*After you click inside the flash plugin*, Mozilla stops receiving the keyboard
shortcut commands, like CTRL+L, ALT+F4, CTRL+2 (access mail), ALT+H (access help
menu), and any other key. If you click away from the Flash plugin (in the HTML
part of a mixed HTML/Flash page), the keys go back to working.

Reproducible: Always
Steps to Reproduce:
1. Load URL http://www.planetoftheapes.com/site_index.html
2. Click inside the Flash plugin, *giving it the focus*
3. Type CTRL+L, or ALT+F4

Actual Results: CTRL+L or ALT+F4 won't have any effect.

Expected Results: CTRL+L should direct me to URL Bar, ALT+F4 should close window.

Marcos.

*** Bug 96091 has been marked as a duplicate of this bug. ***

Why keyword "access"?

"Bugs and enhancement requests related to making Mozilla accessible to users
with disabilities and special needs."

Doesn't seem to fit in this bug. It says disabilities *and* special needs. Not
"or", like in "disabilities or special needs, ie keyb shortcuts".

If I'm wrong, then maybe the description in
http://bugzilla.mozilla.org/describekeywords.cgi isn't well written.

I purpose removing keyword "access".

Marcos.

*** Bug 104829 has been marked as a duplicate of this bug. ***

*** Bug 112299 has been marked as a duplicate of this bug. ***

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any
questions or feedback about this to <email address hidden>. You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

This only happens when the plugin has focus, right? If not, my dups might be
incorrect.

*** Bug 137077 has been marked as a duplicate of this bug. ***

*** Bug 155843 has been marked as a duplicate of this bug. ***

*** Bug 158168 has been marked as a duplicate of this bug. ***

Sergey Lugenov has created a preliminary patch for a bug which seems to be a
dupe of this one, bug 95541.

This is very similar to bug 93149. This one is about app comands like Accel+L,
Accel+W, Alt+F working when the plugin has focus. Bug 93149 is about making the
plugin act as if it's a natural part of the tab order.

Topembed- as this is not currently needed by a major embedding customer.

Jaime, I think this should be topembed+
It's needed by all major embedding customers with accessibility requirements.

renominating. plugin content really does kill keyboard navigation.

sairuh/aaron: do MSIE, 4.x or other browsers currently have this capability?

Yes, IE does.

Load a pdf file up and hit Alt+back arrow. You'll go back in history.
Alt+D will focus the address bar
Alt+F will pull down the file menu
Ctrl+N will open a new browser window.

etc.

Yes, IE is able to process the top menu functions in some plug-ins. The current
plug-in architecture allows for the plug-in vendor to pass unwanted user
functions back to the browser. The npapi code does not analyze each keystroke on
the way to the plug-in. When the plug-in has focus, it has control of the
keystrokes. If the request here is to have the npapi code run an intermediate
layer between the browser and the plug-in and grab those keystrokes that the
browser knows and loves , then plug-ins will not be able to utilize those
functions because they will never reach the plug-in -- is that really what we
want to do here?

What I suggest is that we identify a small handful of crucial keystrokes that we
never give the plugin. Perhaps only a single keystroke that means "Exit plugin".
It could be something uncommon. This way if the plugin swallows all keystrokes
there's still an escape hatch.

All other keystrokes get sent to the plugin, which can either use them or send
them back to us.

*** Bug 175992 has been marked as a duplicate of this bug. ***

*** Bug 176925 has been marked as a duplicate of this bug. ***

*** Bug 180096 has been marked as a duplicate of this bug. ***

*** Bug 180093 has been marked as a duplicate of this bug. ***

*** Bug 180580 has been marked as a duplicate of this bug. ***

*** Bug 176078 has been marked as a duplicate of this bug. ***

Adding nsbeta1+. Peter: we need to work with Aaron to chose a unique key
sequence to exit the plug-in, or ensure that the ALT+[key] is acceptable.

I nominate Shift+Escape, as a "focus the content window" key.

Having such a key to focus the content window would be more generally useful
than just for leaving plugins. A user could hit Shift+Escape to unfocus a form
control, so that tabbing, typeaheadfind and other keys would be available.

I am marking this as a dup of bug 181177. By providing an alt sequence to escape
the plug-in, the user will then have access to the window commands.

A somewhat realated bug is bug 93149, which is now a meta bug for additional
functionality.

*** This bug has been marked as a duplicate of 181177 ***

bug 181177 seems to be an alternative for win32 (and maybe unix?) platforms, but
what about macintosh?

they are being covered sarah

mac is covered by bug 140566.

v dup.

komputes (komputes) on 2008-08-31
description: updated
Changed in flashplugin-nonfree:
status: New → Incomplete
komputes (komputes) on 2009-01-27
Changed in flashplugin-nonfree:
status: Incomplete → Confirmed
Changed in firefox:
status: Unknown → Confirmed
Changed in firefox-3.0:
status: New → Confirmed
Changed in firefox:
importance: Unknown → Critical
Changed in firefox:
importance: Critical → High
Changed in flashplugin-nonfree (Ubuntu):
status: Confirmed → Opinion
komputes (komputes) on 2012-03-20
tags: added: css-sponsored-p
604 comments hidden view all 684 comments

Mozilla took different approach to Chrome - Chrome decided to take back keyboard, FF doesn't want to harm Flash plug-ins that might be using it. That is also why Roth's patch was rejected.

When Flash adopts the NPAPI proposal and makes necessary changes, so will Mozilla. No sooner will this be fixed than that, because otherwise it's hard to test.
I recommend closing this / marking as "won't fix" with appropriate comment "waiting for Adobe".

If someone has information why the approach "not to take back keyboard unless Flash allows us to" was chosen, please share. I'd say it's wrong approach, but my perspective is personal, and perhaps there are facts speaking in favour for plug-ins.

PS. A bit of irony: under the window I'm writing this in, there's "Status: NEW". :-)

I was not aware that this was idealogical issue. I thought it was purely technical!

If that is the case then it seems like the idealogical battle has been already lost, as Firefox is now the only browser that contains this broken UI.

I can guarantee that if we are waiting for all plugin makers (and remember, this isn't just about Flash) to update their plugins to support a spec. that applies to only one browser, well, it just ain't gonna happen!

I just wanted to say that I waited for this for some time, and it wasn't fixed. There was another bug today "Your connection has been reset". Seeing how mozilla manages bug reports, I truthfully didn't have the time to look for a work-around to another problem so now I've passed to Chrome.

BTW - for those of you who "still" have the problem where a plugin doesn't respond to ALT+F4 - I've used a macro command in windows to execute: taskkill.exe /IM firefox.exe /F
So I just pressed my key and firefox would close...
(I have a keyboard with additional assignable macro keys)

If you happen to have a keyboard or a mouse with macro keys, you're in luck :)

Have fun guys!
(I didn't even know there was ad block plus for Chrome - silly me :P )

So this means holding back a better user-experience only because Adobe and other plugin-writers are lazy? Or because there are a couple of old flash-apps which 'might' use keyboard-shortcuts they shouldn't have used at all? Now that's for a strange, user-unfriendly decision.
Take a look at the discussion, the number of votes on this bug. Marking this as WONTFIX equals WEDONTCAREABOUTUSERS imhoe. If this is the state Mozilla is in, it's a sad day for me.

(In reply to LAFK from comment #630)
> Mozilla took different approach to Chrome - Chrome decided to take back
> keyboard, FF doesn't want to harm Flash plug-ins that might be using it.
> That is also why Roth's patch was rejected.
>
> When Flash adopts the NPAPI proposal and makes necessary changes, so will
> Mozilla. No sooner will this be fixed than that, because otherwise it's hard
> to test.
> I recommend closing this / marking as "won't fix" with appropriate comment
> "waiting for Adobe".
>
> If someone has information why the approach "not to take back keyboard
> unless Flash allows us to" was chosen, please share. I'd say it's wrong
> approach, but my perspective is personal, and perhaps there are facts
> speaking in favour for plug-ins.
>
> PS. A bit of irony: under the window I'm writing this in, there's "Status:
> NEW". :-)

(In reply to LAFK from comment #630)
> Mozilla took different approach to Chrome - Chrome decided to take back
> keyboard, FF doesn't want to harm Flash plug-ins that might be using it.
> That is also why Roth's patch was rejected.
>
> When Flash adopts the NPAPI proposal and makes necessary changes, so will
> Mozilla. No sooner will this be fixed than that, because otherwise it's hard
> to test.
> I recommend closing this / marking as "won't fix" with appropriate comment
> "waiting for Adobe".

Isnt firefox about user choice? Please excuse my technical ignorance but why can't there be a about:config pref that allows users to decide if they want plugins or the browser to get hotkeys first?

Seems that a great number of people here want this. If the option is there then there would be no reason to complain! Even if the pref was the default option, the 0.00001% of firefox users that have their flash game broken can set it back no problems. Everyone wins.

I would argue that a change like this affects less people negatively then E4X depredation for addons. Yet, the call was made that the benefits outweighed the negatives. I believe mozilla can do the right thing again.

Stop pleading your case in this bug. They used to say Mozilla was great because open source meant more responsiveness to what users want, then they abandoned that and moved on to "submit a patch", and then they started rejecting patches they didn't like. It should be very clear by now that Mozilla is not about fixing bugs that users want fixed, and they even actively resist patches for bugs users want fixed. This isn't the first bug where this is the case, and it won't be the last. Pleading in here is not going to change the egos involved. Just use Firefox or don't. Their market share will tell them how they're doing.

Few thoughts:

1) I'm quite certain Mozilla had reasons to wait for Adobe/Flash. I'd like to know whether they still stand. Perhaps they don't.

2) I recommended WON'T FIX to Mozilla to actually clear up bug status. It took me a while (and some effort) to actually learn why this bug is NOT being worked upon and what has been done. I'm not tied to Mozilla AT ALL. This means it's my own personal recommendation for Mozilla team IF THEY DECIDE TO STICK WITH WAITING FOR FLASH, which I - again, personally - think is wrong course of action.

Still, it's better then current situation, because every person coming here is bound to misunderstand (pointer to comment 403 doesn't help either).

3) Switching to Chrome and about Open Source (OS) - and plug-ins.

Chrome is actually quite good browser, though proprietary. Chromium is also good, and it's free (OS, non-proprietary). If you find them to your liking, good for you - and I don't write in a "I don't give a damn" way, it's actually true.

OS is open, but it's not free for whoever makes it. And they make mistakes as everybody else. Fixing takes time and effort, these aren't free - and sometimes it's not easy (shouldn't take 12 years, sure, I don't claim otherwise, I think something else is at hand here).

It's good to be passionate about web-browser, but honestly - and I don't mean to preach - I don't think announcing how Chrome is better and FF sucks because of this bug will (don't lynch me yet) speed up the fix coming.

Not trying to defend anyone here, just showing another view of the situation, which might be broader in some aspects. I am an avid fan of mouseless navigation (avid Vimperator and Pentadactyl user) and this bug has been a pain for such a long time now. I totally understand, how frustrating it is and am far from condemning anyone for being irritated at n-th time losing ability to use this-or-that keystroke.

I just think that we may be missing the info on the other side - the plug-in users. They don't come here (obviously, why should they) since they like the way it is. But perhaps it is us, who are in minority. I don't know, but it may be so.

4) Most important. What can help?

So, again, if you guys have the info on plug-in usage, some figures about it, or the knowledge about the reasons Mozilla decided to wait for Flash, please share.

PSA: Every time you post a comment on this bug, you are spamming 375 email addresses. I don't know about you people, but I CC'd myself to this bug so that I could receive updates about what Mozilla developers are doing about it. I did NOT CC myself to this bug so that I could hear people complain about it constantly. I assume the majority of people CC'd to the bug had similar reasoning when adding their email address.

So please do not comment unless you are working at Mozilla, or are a user *providing information about the issue*. This is basic netiquette for every bug tracker ever. Considering that this issue is extremely well understood by Mozilla (though apparently not by most of the people commenting here), there should be no need for users to provide more information about the issue. So in short, STOP COMMENTING UNLESS YOU WORK AT MOZILLA. Thank you.

WHERE THIS BUG STANDS AS OF TODAY

There is a technical side to this issue: Firefox is technically UNABLE TO FILTER THE KEYS: confirmed in comment #3, comment #27, comment #181, comment #185, comment #627 (an explanation rather than a confirmation). The hundreds of comments asking Firefox to "just" filter some keys (often going to a lot of specifics) can only be useful once Firefox can intercept plugin keys - which it can't, see bug 788718.

Mozilla has always wanted to fix this bug by changing the plugin API to allow plugins to send back "unused" keys. This is confirmed in comment #188, comment #315, comment #337. Last time this has been confirmed is end of 2009. There have been a few specific proposals: comment #236, comment #269. But, possibly due to the sheer scale of this work, it has not been completed, and seems more unlikely than ever before.

In comment #487, a patch was proposed by Josh Aas from Mozilla which filters what events plugins see, thus departing from the "let's fix the plugin API" approach. The patch was Linux only. This appears to confirm that at least some people at Mozilla are OK with the "filter the keys" approach. There are other linux-only work-arounds: comment #260, comment #385.

There have been some attempts at fixing the bug by providing a way to unfocus the plugin, sidestepping Firefox's inability to filter keys before the plugin sees them: comment #303, comment #308 and my own comment #446 (in which I failed to actually figure out a way to unfocus the plugin - the fact that the plugin captures all keys was not a problem because I used an OS-wide keyboard hook).

Mozilla is asking for patches, but it's been a while since comment #337 and it's no longer entirely clear whether a patch filtering the keys would still be rejected outright. A comment in bug 788718 from someone at Mozilla would clear up this uncertainty.

There is a bounty standing at $164 as of today on this bug: comment #334.

P.S. I shall be bold now and update the whiteboard to point to this comment. The point of this post is to compensate for Bugzilla's lack of a comment voting feature, making the above comments get lost in the noise, and since comment 403 has been repeatedly called "outdated".

Hvis is where I un-cc. This is spamming my mail, and not a damn thing is beeing done. Firefox has grown slow and unresponsive, and I've gone to Chrome too. Byebye.

1 comments hidden view all 684 comments

But thanks indeed for spamming the bug.

> I did NOT CC myself to this bug so that I could hear people complain about
> it constantly.
Actually I think I’m rather enjoying it :) I love Firefox, no other browser has such an entertaining crowd of frustrated users bashing it in a woefully inadequate bugtracker :)

Roman, comment #385 is not an "other linux-only work-around" compared to comment #487, but the very same.

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0

If enabling the context menu on a flash content, several mouse click are needed to dismiss it. While the context menu is enabled the focus is completely lost and Firefox does not respond to any command.

Please let me know if I should open a new bug for this.

(In reply to Sduibek from comment #532)
> Is there a desktop browser that doesn't experience this bug at all?

Midori Browser

(In reply to LAFK from comment #540)
> (In reply to Alexander Rødseth from comment #495)
> > Josh Aas, which events should be let through, in order to not break a
> > non-trivial number of existing plugin-based applications? It's a fairly
> > minimal amount of key press events that are blocked in my Gtk2 patch (and as
> > I understand, people want additional keys to go to Firefox, like Ctrl-F4 and
> > Alt-D).
>
> Josh,
>
> Please kindly answer, or provide some information on which you base your
> comment #487 (especially "This patch denies plugins many events that they
> have always received" part), so that patch can be tweaked.
>
> If you have some tests/test that you base this of, please share.

This patch do nothing with flash on many sites, but works on youtube. I tested it already.

*** Bug 801880 has been marked as a duplicate of this bug. ***

*** Bug 811225 has been marked as a duplicate of this bug. ***

*** Bug 819566 has been marked as a duplicate of this bug. ***

This ticket was just set to priority P3. According to https://wiki.mozilla.org/Bugzilla:Priority_System , this is a designation for enhancements. Does that mean that this issue is considered an enhancement request rather than a bug report?

(In reply to flamingspinach from comment #650)
> This ticket was just set to priority P3. According to
> https://wiki.mozilla.org/Bugzilla:Priority_System , this is a designation
> for enhancements. Does that mean that this issue is considered an
> enhancement request rather than a bug report?

https://bugzilla.mozilla.org/page.cgi?id=fields.html#priority seems more up to date.

Enhancement requests are characterized by having their Severity set to "enhancement". This one is currently set to "major" instead, which places it only one step lower than a "critical" (i.e. crash, hang or dataloss) bug.

I'm restricting further comments on this bug because it's the issues are well understood (see comment 638), and further comments just spam the 386 users CC'd to this bug. The newsgroups are more suited to general discussion, and developers can update this bug as needed when new information becomes available.

[Comments are restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]

*** Bug 744544 has been marked as a duplicate of this bug. ***

*** Bug 626186 has been marked as a duplicate of this bug. ***

*** Bug 931686 has been marked as a duplicate of this bug. ***

Created attachment 827318
PoC patch for both winless and windowed plugins. (Windows)

This proposal is a sensible workaround (as a "complete" solution would
require the collaboration of every single plugin developer, which
doesn't seem feasible) for Windows. Is my understanding that OSX is
not affected, and a solution already exists for GNU/Linux, please
correct me if I'm wrong.

I've implemented two different strategies, one for plugins running in
its own window, and the other for the winless ones. The first one
installs a keyboard hook, which looks for well known keystrokes, and
passes the focus to the main window when one is found. The second
passes all key events to both the plugin and the DOM, except for the
ones which generates movement events (arrow keys, space,
pageup/pagedown...).

This patch is intended as a Proof-of-Concept, it needs betters
comments, an approved list of keystrokes to watch, and (probably) the
ability to be enabled/disabled via "about:config". But I wanted to
obtain early feedback from the devs prior to investing more work on
it.

Comment on attachment 827318
PoC patch for both winless and windowed plugins. (Windows)

See comment #656.

*** Bug 939422 has been marked as a duplicate of this bug. ***

"The second passes all key events to both the plugin and the DOM, except for the ones which generates movement events (arrow keys, space, pageup/pagedown...)." What does this mean precisely? In Windowless mode, plugins are supposed to return true/false whether they handled any particular keystroke, and we should only propagate the keystroke if the plugin didn't handle it. This works on Mac, IIRC: does it not work on Windows (at least for the popular plugins)? We can't have arrow keys that move the page around and also do things within the plugin like text navigation or gaming commands.

Are control-t/w/r localized? I suspect they are, and so we can't just hardcode the English letters, but really need the application frontend to tell the plugin which keystrokes are "special". Also, for plugins that install subwindows (Acrobat), does this keystroke hook still work? Or is this primarily for Flash?

jmathies will be the eventual reviewer for this, but I think we should probably break it apart into the windowless and windowed-mode patches, which are pretty different.

*** Bug 938309 has been marked as a duplicate of this bug. ***

In , Sjw (sjw) wrote :

*** Bug 936902 has been marked as a duplicate of this bug. ***

Sergio, will you be able to address comment 659?

(In reply to Benjamin Smedberg [:bsmedberg] from comment #659)
> "The second passes all key events to both the plugin and the DOM, except for
> the ones which generates movement events (arrow keys, space,
> pageup/pagedown...)." What does this mean precisely? In Windowless mode,
> plugins are supposed to return true/false whether they handled any
> particular keystroke, and we should only propagate the keystroke if the
> plugin didn't handle it. This works on Mac, IIRC: does it not work on
> Windows (at least for the popular plugins)? We can't have arrow keys that
> move the page around and also do things within the plugin like text
> navigation or gaming commands.

This patch, instead of killing all events going to the plugin, only kills the ones that will generate movement on the page (UP, DOWN, LEFT, RIGHT, SPACE...). I don't know about Mac, but on Windows, Java applets (or, at least, the ones I've tested) doesn't properly return the event feedback to the browser.

> Are control-t/w/r localized? I suspect they are, and so we can't just
> hardcode the English letters, but really need the application frontend to
> tell the plugin which keystrokes are "special".

Yes, there should be a way for enabling/disabling this functionality, and for configuring which keystrokes should be processed/ignored. I'm not familiar with the "mozilla way" for doing this kind of things, but if you could point me to dome docs or a piece of code with similar functionality, I can give it a try.

> Also, for plugins that install subwindows (Acrobat), does this keystroke hook still work? Or is
> this primarily for Flash?

Yes, it should. In fact, even if it appears to be embedded, Flash is just a bunch of windows which share the Device Context with the browser. The problem I've noticed with some plugins, is that with some of them the instance owner doesn't notice when they request focus, so the hook doesn't get installed. But this just means that we should look for another place for installing it.

> jmathies will be the eventual reviewer for this, but I think we should
> probably break it apart into the windowless and windowed-mode patches, which
> are pretty different.

I'm OK with this.

> This patch, instead of killing all events going to the plugin, only kills
> the ones that will generate movement on the page (UP, DOWN, LEFT, RIGHT,
> SPACE...). I don't know about Mac, but on Windows, Java applets (or, at
> least, the ones I've tested) doesn't properly return the event feedback to
> the browser.

That doesn't answer my question. Does the patch kill the events *before* they get to the plugin, or *after*? We must certainly send plugins the arrow keys and space.

> > Are control-t/w/r localized? I suspect they are, and so we can't just
> > hardcode the English letters, but really need the application frontend to
> > tell the plugin which keystrokes are "special".
>
> Yes, there should be a way for enabling/disabling this functionality,

The Firefox frontend should be in charge of this: perhaps the best option is to have an API that the Firefox frontend can call "set browser shortcut keys" and then the Firefox frontend can collect the keys that matter from the <command> elements in the Firefox chrome.

> > Also, for plugins that install subwindows (Acrobat), does this keystroke hook still work? Or is
> > this primarily for Flash?
>
> Yes, it should. In fact, even if it appears to be embedded, Flash is just a
> bunch of windows which share the Device Context with the browser.

Flash is typically a single subwindow. Acrobat is a whole hierarchy of subwindows, and we only hook keystrokes for the toplevel window. That's why I was asking about it.

*** Bug 973760 has been marked as a duplicate of this bug. ***

komputes (komputes) on 2014-03-30
summary: - Firefox cannot close tab (using Ctrl-w) when flash content is selected
- on page
+ Cannot use firefox keyboard shortcuts when flash object is selected
description: updated
In , Dao (dao) wrote :

*** Bug 1029444 has been marked as a duplicate of this bug. ***

mikhail-777 (wpr-oxym) wrote :

Partial solution of the problem provides this FIrefox/Seamonkey addon:
https://addons.mozilla.org/En-us/firefox/addon/focus-regainer/
Or lite version:
https://addons.mozilla.org/En-us/firefox/addon/focus-regainer-lite/
But lite version of addon currently has problems with iframes.

*** Bug 1077155 has been marked as a duplicate of this bug. ***

*** Bug 1111982 has been marked as a duplicate of this bug. ***

Changed in firefox:
status: Confirmed → Fix Released
Displaying first 40 and last 40 comments. View all 684 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.