13
edits
Rudisherry (talk | contribs) (Created page with "= Status = Under Consideration = Contributors = * Last modified: March 14, 2012 * Authors: Rudi Sherry (Adobe Systems) * Contributors: = Overview = Currently there are no m...") |
Rudisherry (talk | contribs) |
||
Line 16: | Line 16: | ||
Another reason, especially on the mac, is that all the browsers look in the same places, in the same way, for plugins to support mime types. Any plugin that supports only one of those browsers has no way of "politely refusing" to run in the other. | Another reason, especially on the mac, is that all the browsers look in the same places, in the same way, for plugins to support mime types. Any plugin that supports only one of those browsers has no way of "politely refusing" to run in the other. | ||
This is especially the case for complex plugins that use OS APIs that, for some reason, don't work in certain browsers, do work in others, and would also work in a downloaded resource launched by the default application. | |||
In this case, on detecting that the browser was one that didn't support it, the plugin could do the downloading and launch the other application. To do this in a way that doesn't surprise or confuse the user, it would have to look like the browser was doing it. This is a simpler alternative, since the code already exists in the browser for: | |||
* asking about downloads in the user's language | |||
* placing them in a common well-known Downloads location | |||
* allowing the user to track the download from the browser | |||
* launching the default app (or not) | |||
* allowing the user to delete the download from the browser | |||
etc. | |||
This proposal is to add a mechanism to allow plugins to politely "opt-out" when two existing NPAPI calls are made. | This proposal is to add a mechanism to allow plugins to politely "opt-out" when two existing NPAPI calls are made. |
edits