[whatwg] Application defined "locks"
darin at chromium.org
Wed Sep 9 22:04:23 PDT 2009
On Wed, Sep 9, 2009 at 10:01 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
> On Thu, Sep 10, 2009 at 4:57 PM, Darin Fisher <darin at chromium.org> wrote:
>> On Wed, Sep 9, 2009 at 9:43 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>> On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher <darin at chromium.org>wrote:
>>>> Imagine if you script a plugin inside the transaction, and before
>>>> returning, the plugin scripts another window,
>>> I'm curious, how common is that anyway? Can we just tell plugins not to
>>> do that, and abort any plugin that tries?
>> I don't know. Are you saying that a plugin should not be able to invoke a
>> function that may trigger showModalDialog? The code that calls
>> showModalDialog may be far removed / unrelated to the plugin script. It may
>> just be an unfortunate side effect of invoking a method on a DOM window.
> No, I'm saying when a script in window A calls into a plugin, the plugin
> should not be allowed to synchronously call back out to script in window B.
> I realize that is currently "allowed" (i.e. not forbidden by anything in
> NPAPI), but do plugins actually do it in practice?
Yes, this is something that we have observed real plugins doing. It is easy
for a plugin to have references to multiple windows. They also like to
script the page in response to random NPP_ calls, like NPP_HandleEvent and
NPP_SetWindow, which perhaps is not too surprising. NPP_HandleEvent
generally corresponds to input processing and painting for windowless
plugins, and NPP_SetWindow corresponds to a resize event.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg