[whatwg] Application defined "locks"

[Darin Fisher]

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.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/31652b28/attachment.htm>