Proposal for plugins "opting out" of handling resources
rsherry at adobe.com
Wed Mar 21 14:09:42 PDT 2012
I added text to the overview to try to more explain the case. "Browser-neutral" is hard, especially for complex plugins with lots of UI (it's no secret that I work on Adobe Reader).
The feature-based suggestion is valid, since we're having trouble with certain browsers' support for things we do (a list of features we'd have to ask about is below). The proposal would change very slightly, since I still would be requesting some way for the browsers to pretend we're not there (which is the real meat of the proposal).
The issues we're seeing are extremely subtle platform-based capabilities (we're working on the mac), so to do feature-detection, we'd need the answer to these:
* are you 32-bit or 64-bit
* does your plugin process allow NSWindows to be created?
* 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)
* does your plugin process have an NSApplication? Does it respond to [postEvent:atStart:]?
* do you send NPAPI events synchronously or asynchronously?
* do you make modal dialogs from the plug-in process to be window-modal (or app-modal) to your browser process?
You can see we could get the answer to most of these without bothering with feature-detection; for some of them we already know at NP_Initialize() time. Others we would have to ask.
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). We can detect we're in, say, Firefox or Safari 32-bit, but here is no way we can "hide" from only it (and not hide from the 64-bit version), as far as I can see: our info.plist is our info.plist for both architectures and all can read it.
To forestall the obvious and reasonable suggestion that we find what's going wrong in 32-bit Snow Leopard and work around it, yes we are working on that but are not hopeful, are quite resource-challenged, and don't want to delay support for the (default) 64-bit browser because the (non-default) 32-bit browser won't work. I'm sure as a developer you can relate.
The best workaround IMHO, if we can't show a PDF in the browser, would be to have the browser do native display of the PDF if it can, or if it can't (or doesn't want to) have it offer to download and launch the default PDF handler application. Much like a user turning off the plug-in. All the browsers already have very sophisticated and elegant solutions for showing some kind of default content, and/or downloading mime types they don't support (including localized dialogs, download management etc)... and I'd like the plugins to be able to leverage that.
Does that make sense?
On Mar 14, 2012, at 1:25 PM, Stuart Morgan wrote:
> For the initialization check: encouraging plugin vendors to have their
> plugin decide whether or not to load based on UA seems like an
> anti-feature. Can you provide specific examples of reasons a plugin
> written in what is intended to be a browser-neutral format would need
> to use a browser whitelist or blacklist? A solution that's more
> analogous to feature-detection would be much better if it's feasible.
> Le 14 mars 2012 21:06, Rudi Sherry <rsherry at adobe.com> a écrit :
>> I just added a proposal wherein a new error code means the plugin would like to politely refuse to load, or handle a specific stream, and the browser would then use its default implementation as if the plugin didn't exist.
>> The actual API changes are minimal: one new error code for some existing NP/NPP routines.
>> Questions? Comments?
>> plugin-futures mailing list
>> plugin-futures at mozilla.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3399 bytes
Desc: not available
More information about the plugin-futures