(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. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to flashplugin-nonfree in Ubuntu. https://bugs.launchpad.net/bugs/263435 Title: Firefox cannot close tab (using Ctrl-w) when flash content is selected on page Status in The Mozilla Firefox Browser: Confirmed Status in “firefox-3.0” package in Ubuntu: Confirmed Status in “flashplugin-nonfree” package in Ubuntu: Opinion Bug description: Binary package hint: flashplugin-nonfree Firefox cannot close tab (using Ctrl-w) 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 To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/263435/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
