For future releases of the Adobe Flash Player for Unix platforms, we would like to use a better method of integrating with the encapsulating web browser. This method is known as XEmbed. It is supported by some Unix web browsers but not all. Naturally, the best reason for a browser to support this interface would be if the Flash Player supported it. But without a reasonable test plugin, browser authors are a little stuck.

That’s why I threw together such a test plugin. Further, my corporate masters have authorized me to release it as open source! I call the plugin DiamondX. It operates by drawing a diamond in the specified plugin space as such (note that this is a static image and not the actual plugin in action):


The plugin can pop up a few modal dialog boxes which ought to be honored by the browser. There is a better-looking context menu than the one seen in the current Flash Player. Via the standard output, the plugin will also communicate which relevant events it is receiving. And get this: Keyboard focus should not follow the mouse with this example plugin!

There will hopefully be more iterations of this plugin as I plan to use it as a testbench for implementing windowless support (a.k.a. wmode, transparency) in the plugin. This way, Linux can finally be on equal footing with Windows and Mac for displaying the kind of advertisements that take over the entire browser window. And I know Linux users want that. Seriously, there are legitimate uses for said feature as highlighted by the oft-reported “Javascript menus are covered by SWF” bug.

So download DiamondX, compile it, and try it out with your favorite browser. If your favorite browser does not yet have XEmbed support, you may wish to ask the authors to think about implementing it.

11 Responses to Bling

  1. Anonymous says:

    I hope this will help Firefox/Seamonkey developers to improve flash support. I hope the “Javascript menus are covered by SWF” bug will be fixed.I hope this will solve “grey background under transparent flash animation” bug too:

  2. Arren Lex says:

    Any chance this will make flash player crash less? Or at least not take the browser with it when it does? :(The plugin worked perfectly in firefox, but it didn’t load in konqueror: nspluginviewer (plugin): ERROR: Can’t create plugin class

  3. James C says:

    Currently Firefox on Linux still has the menu overlay bug with this plugin, but if it helps them put the bug to bed, awesome. Exhibit AAlso, for those messing around on Ubuntu, I had to edit the Makefile and changes references of nspr to mozilla-nspr for it to find nspr to compile with (using the libnspr-dev package).Thanks for the great work Mike!

  4. Tomer Chachamu says:

    “It is supported by some Unix web browsers but not all.”Name them and shame them.

  5. Vedran Rodic says:

    Sounds great. I guess this one also fixes mouse wheel not working when it’s over a flash animation. I suggest making the beta Xembed version of the flash plugin available as soon as possible. [ Actually, no. Even when the mouse scroll wheel event goes unhandled by the plugin, it does not seem to propagate up to the host application. -Mike M. ]

  6. Lars says:

    I notice that XEmbed allows plugins to run out-of-process. Are you planning to have the future Flash plugin run this way? If you did, and managed to have the browser glue open-sourced, we could finally use the plugin in 64-bit browsers.Thanks for continuing to support us Unix folks! [ From what I can tell, running out-of-process isn’t necessarily a function of the XEmbed protocol, even though the Mozilla page makes reference to it. -Mike M. ]

  7. chodo says:

    Cool! That sounds really good. I hope the FF-Coders get their ass moved! 😉

  8. Madarco says:

    I’m more interested in the “Javascript menus are covered by SWF” bug, since the possibility to put a swf not only “on top” of a web page would lead to a better integration.For the mouse wheel there is a work around:

  9. Rodolfo Martinez says:

    That’s great if it does fix the SWF is over the javascript menus – now I just need to work! (both worked using gnash).

  10. Frucomerci says:

    Hey! Seems pretty good, XEmbed will rocks! I have tried many times to find something similar but I couldn’t!thanks for the info,nice blog

  11. Jaap Weel says:

    “And get this: Keyboard focus should not follow the mouse with this example plugin!”I’m a little confused here. You speak of “modal” dialogs. I take it, or hope, that this means simply that while the dialog is popped up, clicking in the plugin window (i.e. the part of the web page that represents the contents of the tag) should have no effect, even if the window manager is set to focus-follows-mouse. Presumably, the reason for this is that you want the plugin author to be able to specify something like “are_you_sure = get_yes_no_from_user();” and be sure that this is synchronous and you don’t have events coming in before the call returns.But the other interpretation I could see is that you want the entire browser to ignore click events while the popup is popped up. I could vaguely understand why you might want that, but I don’t (that is, I don’t want it). When I have two tabs open, and one of them is displaying a page that includes a plugin, I want to be able to view the other tab no matter what the plugin says. [ It’s the latter — when the plugin pops up a modal dialog, the browser should ignore all other events until the dialog is dismissed. No switching between tabs. This is the same policy in Firefox if you were to open a file dialog box while in one tab; you would not be able to switch to another tab before dismissing that dialog. -Mike M. ]