Zack has a long blog about browser plugins. And he advocates going the XEmbed route. Originally I wrote this as a comment, but I think more people should know about the mess that is called browser plugins.
Swfdec used to be an out-of-process plugin. That plugin had all the nice features he mentions, but utterly fails for other things:
- translucency. If you use an X window for embedding as in XEmbed, you suddenly need Composite support to be able to do it.
- z-order. It’s absolutely fine to pop up a DIV on top of any plugin. If you go the X-Window route, you’re in for quite a ride since suddenly you have to create an X-Window for (at least) every DIV.
- Input events. You know when you use the mouse wheel on top of an embedded Flash animation and it doesn’t scroll? Or when you press Ctrl-T to open a new tab and none opens because the plugin has keyboard focus? Those.
So how would I solve the current mess? I would go the same route every other application with plugins goes. I’d write one plugin for every application. There’s really no need to have shared plugins. Noone wants to run Rhythmbox plugins in Amarok or Konq plugins in Nautilus.
If every browser had its own plugin system, suddenly Swfdec could use all the nice APIs of the browser. It could integrate its properties with the Konq properties dialog. It could share common properties (“run animations [x] always [ ] once [ ] never”, “sound [ ] enabled [x] disabled”), it could react to events (like ESC stopping animations). And there’ll probably be lots more I’m missing.
I can imagine two reasons why browsers didn’t go that route. The first is closed source plugins. Adobe ships Flash only for Moz plugins. So everyone tries to add support for that one plugin. And the second reason is that there really isn’t a huge demand for plugins. There’s really only Flash and Video players. Integrate those two natively and you don’t even need plugin support at all.
Oh, and one final note. Please stop bringing up the “misbehaving plugins” argument. It’s the reason for so much braindead code trying to cope with “misbehaving” stuff. If some code is broken, fix the broken code, don’t try to work around it. It feels like advocating to render every tab out-of-process, because then one page crashing doesn’t kill the browser…
3 comments ↓
If I remember correctly, the reason there’s one plugin API is that Netscape implemented it first, and then Microsoft implemented a compatible API for IE so that plugins that already existed would work in IE without having to get a new version written for that browser (which was a lot less popular than Netscape back then). At that point the two browsers which had almost all the browser market both used the NS plugin API, which gave a third browser basically no choice but to implement it too…and ten years later we’re still stuck with it.
I’ve not looked at the NS plugin API, but is it the API that means we have to implement it with XEmbed? Perhaps an in-browser implementation can be made that doesn’t use XEmbed but still provides the compatible API?
Also, the whole out-of-process argument is rubbish anyway, Firefox/epiphany still crash/halt when a plug-in crashes/halts… Seems only Konqueror takes advantage of this :(
1) everyone should have composite. it will be very difficult to get by without it in the near future.
2) you don’t need to do this. you can use composite to fake z-order. of course for this you need:
3) improved xembed event forwarding semantics. uhm…. lots of people have said “this would be nice” but nobody has seemed to do anything yet.