Proposal for plugins "opting out" of handling resources

Rudi Sherry rsherry at adobe.com
Fri Mar 23 08:10:49 PDT 2012


Stuart, these are not unreasonable objections and I will withdraw the proposal.

I am actually in agreement with most of what you say and wish we had the manpower to take the very large body of existing infrastructure and UI and re-architect them to be browser neutral and use CALayer.  Lacking anything even close to that, though, we will fall back to our plan (as you also suggested) and show an "incompatible" alert.

Pointing them to a help page could mitigate things a bit; I will try to find resources for creating and maintaining that page (localized into n languages of course).

Alternatively, perhaps when we install, we can pre-install whatever it is that Chrome needs for us to be disabled (the installation process need not mention Chrome so the user is not led to believe it will work there). Is there a way to do that?  I couldn't find anything specific on the web.

-- Rudi

On Mar 22, 2012, at 5:33 AM, Stuart Morgan wrote:

> Le 21 mars 2012 22:09, Rudi Sherry <rsherry at adobe.com> 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 developer.apple.com 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
> idea.
> 
> 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.
> 
> -Stuart

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3399 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/plugin-futures/attachments/20120323/06d4e52b/attachment.bin>


More information about the plugin-futures mailing list