Cannot use firefox keyboard shortcuts when flash object is selected

Bug #263435 reported by komputes
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

Revision history for this message
In , Dshultz (dshultz) wrote :

Macromedia Bug 67613

Revision history for this message
In , Peterlubczynski-bugs (peterlubczynski-bugs) wrote :

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.

Revision history for this message
In , Peterlubczynski-bugs (peterlubczynski-bugs) wrote :

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.

Revision history for this message
In , Karnaze (karnaze) wrote :

Moving to m0.9.2

Revision history for this message
In , Peterlubczynski-bugs (peterlubczynski-bugs) wrote :

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

Revision history for this message
In , Peterlubczynski-bugs (peterlubczynski-bugs) wrote :

-->mozilla0.9.4

Revision history for this message
In , Shrir (shrir) wrote :

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

Revision history for this message
In , Mdimitrio (mdimitrio) wrote :

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.

Revision history for this message
In , Mdimitrio (mdimitrio) wrote :

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.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

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

Revision history for this message
In , Mdimitrio (mdimitrio) wrote :

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.

Revision history for this message
In , Jruderman (jruderman) wrote :

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

Revision history for this message
In , Bugzilla-iwaruna (bugzilla-iwaruna) wrote :

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

Revision history for this message
In , Scottputterman (scottputterman) wrote :

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.

Revision history for this message
In , Jruderman (jruderman) wrote :

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

Revision history for this message
In , Jruderman (jruderman) wrote :

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

Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

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

Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

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

Revision history for this message
In , AleksanderAdamowski (aadamowski) wrote :

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

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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.

Revision history for this message
In , Bugz-jeziorek (bugz-jeziorek) wrote :
Revision history for this message
In , Jaimejr (jaimejr) wrote :

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

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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

Revision history for this message
In , Bugzilla-iwaruna (bugzilla-iwaruna) wrote :

renominating. plugin content really does kill keyboard navigation.

Revision history for this message
In , Jaimejr (jaimejr) wrote :

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

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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.

Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

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?

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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.

Revision history for this message
In , Wd-pobox (wd-pobox) wrote :

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

Revision history for this message
In , Wd-pobox (wd-pobox) wrote :

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

Revision history for this message
In , Spam-minneboken (spam-minneboken) wrote :

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

Revision history for this message
In , Spam-minneboken (spam-minneboken) wrote :

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

Revision history for this message
In , Spam-minneboken (spam-minneboken) wrote :

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

Revision history for this message
In , Cplyon (cplyon) wrote :

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

Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

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.

Revision history for this message
In , Aaronleventhal (aaronleventhal) wrote :

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.

Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

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 ***

Revision history for this message
In , Bugzilla-iwaruna (bugzilla-iwaruna) wrote :

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

Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

they are being covered sarah

Revision history for this message
In , Bugzilla-iwaruna (bugzilla-iwaruna) wrote :

mac is covered by bug 140566.

v dup.

komputes (komputes)
description: updated
Changed in flashplugin-nonfree:
status: New → Incomplete
komputes (komputes)
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)
tags: added: css-sponsored-p
620 comments hidden view all 700 comments
Revision history for this message
In , Wproxym (wproxym) wrote :

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

Revision history for this message
In , Mardeg (mardeg) wrote :

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

Revision history for this message
In , Manuela-muntean (manuela-muntean) wrote :

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

Revision history for this message
In , Simona-marcu (simona-marcu) wrote :

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

Revision history for this message
In , Flamingspinach (flamingspinach) wrote :

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?

Revision history for this message
In , Antoine-mechelynck-gmail (antoine-mechelynck-gmail) wrote :

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

Revision history for this message
In , Dolske (dolske) wrote :

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

Revision history for this message
In , Kbrosnan-mozilla (kbrosnan-mozilla) wrote :

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

Revision history for this message
In , Paul-silaghi (paul-silaghi) wrote :

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

Revision history for this message
In , Kevin Brosnan (kbrosnan) wrote :

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

Revision history for this message
In , Mozilla-z (mozilla-z) wrote :

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.

Revision history for this message
In , Josh Matthews (joshmatthews) wrote :

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

See comment #656.

Revision history for this message
In , Davemgarrett (davemgarrett) wrote :

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

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

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

Revision history for this message
In , Lhenry (lhenry) wrote :

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

Revision history for this message
In , Sjw (sjw) wrote :

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

Revision history for this message
In , Josh Matthews (joshmatthews) wrote :

Sergio, will you be able to address comment 659?

Revision history for this message
In , Mozilla-z (mozilla-z) wrote :

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

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

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

Revision history for this message
In , Alice0775 (alice0775) wrote :

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

komputes (komputes)
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
Revision history for this message
In , Dao (dao) wrote :

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

Revision history for this message
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.

Revision history for this message
In , Bugzilla-tf (bugzilla-tf) wrote :

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

Revision history for this message
In , Glob-8 (glob-8) wrote :

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

Revision history for this message
In , Bugs-1 (bugs-1) wrote :

(In reply to Benjamin Smedberg [:bsmedberg] from comment #664)
> 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.

This sounds like a fine approach. Would it be acceptable to intercept all the keys that fit this category?

Revision history for this message
In , Kbrosnan-mozilla (kbrosnan-mozilla) wrote :

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

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

I suspect not: Control-C/V/X at least still need to go to the plugin.

Revision history for this message
In , Gingerbread-man-2 (gingerbread-man-2) wrote :

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

Revision history for this message
In , Dirkjan Ochtman (dirkjan-ochtman) wrote :

Sergio, would you still be interested in working on this? If not, would it be possible to put this on a backlog somewhere? Personally, I'm mostly concerned about Flash and CTRL + W (that is, tab closing)...

Revision history for this message
In , Vseerror (vseerror) wrote :

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

Revision history for this message
In , Epinal99-bugzilla2 (epinal99-bugzilla2) wrote :

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

Revision history for this message
In , Masayuki (masayuki) wrote :

This is now (Fx 48~), fixed by bug 1203059 only for "reserved" shortcut keys.

If you think that it's not enough to reserve shortcut keys for some functions, please file a bug for each shortcut key.

Our agreement is, we do NOT enable whole shortcut keys on plugins, e.g., Ctrl+C, etc. So, be careful when you judge if a shortcut key should be "reserved".

Revision history for this message
In , Masayuki (masayuki) wrote :

FYI:

Windows specific fix: bug 1257759
Mac specific fix: bug 1257760

And note that this is WONTFIX on Linux due to event handling model limitation, technically.

Revision history for this message
In , Arni2033 (arni2033) wrote :

>>> My Info: Win7_64, Nightly 49, 32bit, ID 20160526082509
                (all bugs mentioned in comment 676 , comment 677 are already fixed)
STR:
1. Open attachment 8675621
2. Click in searchbar, then click on the flash
3. Press Ctrl+L, or one of the following: Ctrl+N, Ctrl+W, Ctrl+F4, Ctrl+T, Ctrl+Tab

AR: None of them work (tested in both e10s and non-e10s modes)
ER: At least some said hotkeys should work (it's really UNCLEAR what hotkeys exactly are "reserved")

So I will (try to) reopen this if there's no reasonable response from your side in 24 hours.

Revision history for this message
In , Masayuki (masayuki) wrote :

Hey, I said, "If you think that it's not enough to reserve shortcut keys for some functions, please file a bug for each shortcut key".

And Ctrl+N, Ctrl+W and Ctrl+T should work on Windows. They are reserved shortcut keys.

Revision history for this message
In , Masayuki (masayuki) wrote :

And nobody shouldn't reopen this bug because I implemented a way to override shortcut keys even if a plugin has focus. So, if you find specific problem, please file a bug for each problem. This bug has too many CC list and a lot of comments. So, it doesn't make sense to keep discussing on this bug.

Changed in firefox:
status: Confirmed → Fix Released
Revision history for this message
In , Arni2033 (arni2033) wrote :

Release Note Request (optional, but appreciated)
[Why is this notable]: Anyone who ever used Firefox is aware of this annoying bug, and now it's fixed
[Suggested wording]: Reserved Firefox shortcuts now work in plugins like Flash & Acrobat Reader
[Links (documentation, blog post, etc)]: https://bugzilla.mozilla.org/show_bug.cgi?id=78414#c676

Revision history for this message
In , Dao+bmo (dao+bmo) wrote :

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

Revision history for this message
In , Liz Henry (lizhenry) wrote :

Removing the release note flag. Whatever was going on here was happening in the Firefox 48 timeframe.

Revision history for this message
In , Virtual-q (virtual-q) wrote :

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

Displaying first 40 and last 40 comments. View all 700 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.