[whatwg] Application defined "locks"

[Robert O'Callahan]

On Thu, Sep 10, 2009 at 4:11 PM, Darin Fisher <darin at chromium.org> wrote:

> On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher <darin at chromium.org> wrote:
>>
>>> What concerns me are the cases where synchronous events (e.g., resizing
>>> an iframe) can cause script to execute in another domain.  As spec'd, there
>>> is a potential dead lock with the storage mutex.  We must carefully unlock
>>> in situations like this.  However, such unlocking will appear quite
>>> mysterious to users, so much so that I question the value of the implicit
>>> storage mutex.
>>>
>>
>> Right now I'm not sure how big a problem this actually is. The resize
>> event for a document in a frame can surely be dispatched asynchronously so
>> no unlocking is required. I would like to have a much better idea of how
>> many places absolutely must release the storage mutex before deciding that
>> approach is unworkable.
>>
>> Rob
>>
>
> What about navigating an iframe to a reference fragment, which could
> trigger a scroll event?  The scrolling has to be done synchronously for
> compat with the web.
>

The scrolling itself may have to be synchronous, at least as far as updating
scrollLeft/scrollTop if not visually ... but in this case the script
execution in the frame would be an onscroll event handler, right? That's
asynchronous in Gecko.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090910/a9e3b94c/attachment-0002.htm>