Cannot use firefox keyboard shortcuts when flash object is selected

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.

-->mozilla0.9.4

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

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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.

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

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

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

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