[whatwg] Application defined "locks"
darin at chromium.org
Wed Sep 9 21:54:49 PDT 2009
On Wed, Sep 9, 2009 at 9:28 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
> 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.
>> 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.
Interesting. Gecko seems to be the odd man out there. Both MSHTML and
WebKit dispatch the onscroll event handler synchronously. Maybe my
assertion about that being important for web compat was overreaching.
At any rate, this should at least give us pause. There could be other ways
in which script execution across domains could be nested :-/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg