Proposal for plugins "opting out" of handling resources

Stuart Morgan stuartmorgan at
Thu Mar 22 05:33:39 PDT 2012

Le 21 mars 2012 22:09, Rudi Sherry <rsherry at> a écrit :
> "Browser-neutral" is hard, especially for complex plugins with lots of UI

Based on the list you give below, it seems like "lots of UI" actually
means "unsupported methods of showing UI". Drawing your UI in the
plugin's visual region, which is where plugins are supposed to put
their UI, should be pretty easy to make browser-neutral.

> * does your plugin process allow NSWindows to be created?
> * do you make modal dialogs from the plug-in process to be window-modal (or app-modal) to your browser process?

I don't think there's any browser vendor who considers this supported;
for example, there used to be a page about NPAPI
plugins (it seems to be gone now), and it explicitly discouraged
creating windows. I know that for Mac Chrome we got this working just
well enough that existing plugin reliance on windows (most notably the
open panel in Flash) mostly worked, but the user experience is always
going to be poor for windows opened by OOP plugins. They won't show in
the window list, making them "modal" is a hack at best, etc. It's
concerning to hear that a new plugin is being developed that relies on
opening windows in the plugin process.

> * does your CoreAnimation model support using a layer that is already backing up an NSWindow
> in another process? (Safari does, Firefox does in some versions, not sure about Chrome)

Relying on esoteric implementation details of the way the browser
displays the CALayer you vend seems unwise regardless of what happens
with this proposal. Mac Chrome has tweaked the pipeline several times,
and may well again; it sounds like the same may be true of Firefox.
That could make for a very poor experience for users who suddenly find
that the plugin is broken (and not even OPT_OUTed) when they
auto-update to the latest browser version.

> As for 32/64 bit, Snow Leopard running 32-bit apps doesn't support what we want to do with OS
> routines, but it does when running 64-bit apps (and Lion works in both).

It sounds like what you are trying to do is simply not well suited to
NPAPI; it sounds like important parts of your planned UX are based on
things that browsers don't officially support and are in at least some
cases actively discouraged. The idea of adding something to the NPAPI
spec whose sole purpose sounds like it would be encouraging the
creation of plugins that are based on unsupported approaches that only
work in some browsers (probably by luck) concerns me quite a bit.

> Much like a user turning off the plug-in.

Except that when a user turns a plugin off, they know what's
happening. Separately from the philosophical question of whether this
belongs in the platform at all, the user experience seems like it
would be pretty confusing: the user installs a plugin, opens a page
with the relevant content, and sees... exactly what they saw before.
Maybe they know about their browser's plugin-display UI, or maybe they
post on a user support form and get pointed there by a more
knowledgeable user, and when they go there they see an enabled plugin
that handles the right type. Why is it being ignored? They have no

>From the browser side, this would almost certainly lead to a bunch of
bug reports and user support requests because the obvious conclusion
if two browsers see a plugin but one is ignoring it for no apparent
reason is that there's a browser bug.

If a vendor were going to deliberately ship a plugin that didn't work
on Chrome, I would see it as more user-friendly for them to have their
plugin display a message that explained that Chrome wasn't supported,
and linked to a help page that told them how to disable the plugin in
Chrome, since then the user would understand what is happening.

I understand that Safari doesn't have similar UI you could point users
to, so I do understand the motivation for the proposal from your side.
But from my perspective, it's a proposal that would make it trivial
for a plugin vendor to create a more confusing experience for Chrome
users (in a case that I would argue shouldn't exist in the first
place). It's hard for me to see why we would want to support that.


More information about the plugin-futures mailing list