[whatwg] Worker feedback

[Darin Fisher]

On Mon, Apr 6, 2009 at 4:20 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Mon, Apr 6, 2009 at 7:03 PM, Darin Fisher <darin at chromium.org> wrote:
>
>> On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow <jorlow at google.com> wrote:
>>>
>>>> If I understood the discussion correctly, the spec for document.cookie
>>>> never stated anything about it being immutable while a script is running.
>>>
>>>
>>> Well, there never was a decent spec for document.cookie for most of its
>>> life, and even if there had been, no implementations allowed asynchronous
>>> changes to cookies while a script was running (except for maybe during
>>> alert()) and no-one really thought about it. Was this even identified as a
>>> possible issue during Chrome development?
>>>
>>
>> In addition to alert(), don't forget about all the great state changing
>> things that can happen to the cookie database (and other data stores) during
>> a synchronous XMLHttpRequest (or synchronous document.load) in Firefox.
>>  Maybe those are just bugs?  What if a Firefox extension wants to muck
>> around with the cookie database while a web page is blocked on a synchronous
>> XMLHttpRequest?  Maybe that should fail to avoid dead-locking?  Sounds like
>> a recipe for flaky extensions since it is unlikely that the extension author
>> would have been prepared for being called at this time when access to the
>> cookie database would have to be denied.
>>
>
> According to the spec the storage mutex is dropped for blocking operations
> like alert() and sync XHR, and as you know, that's effectively what we do.
>
> But the general rule of DOM API design is that operations do not block and
> we offer asynchronous APIs instead. alert() and sync XHR are exceptions to
> this rule, but they're ugly stepchildren of DOM APIs and we don't want to
> treat them as norms.
>

OK... so if I am building an API, the consumer of my API might not realize
that I have stuck a sync XHR in the middle of it.  (People often do that so
that their API can work during unload.)  So the consumer of such an API now
has to deal with the cookie lock being released?



>
>
> When deciding how to handle cookies in Chrome, we did not worry about the
>> problem being debated here.  Our concerns were allayed by recognizing that
>> IE does not try to solve it (and IE6 is multi-process just like Chrome with
>> a shared network stack), so clearly web developers must already have to
>> cope.
>>
>
> You mean IE8.
>

No, IE6,7,8 (maybe older versions too?) ... you can launch multiple IE6
processes, and those share cookies.  You can also programmatically access
the same cookies via WinInet from any application.  It is not uncommon for a
separate application to be mucking around with cookies for intranet.com.



>
> How would Web developers cope? There's no way to synchronize. I doubt more
> than a handful of Web developers even know this problem could exist.
>

You can synchronize through the origin server...

What I meant was that they "cope" by not expecting document.cookie to return
the same results each time it is called.  I'd imagine it is not uncommon for
users to login to a site in multiple windows and perform similar operations
in each browser window.  That scenario seems like it could trigger what we
have here.




>
> I think it would be best to specify that document.cookie returns a
>> snapshot.  I think that is consistent with existing implementations
>> including IE, Firefox, and Chrome.
>>
>
> Not at all. In Firefox, cookies don't change while a script is running, as
> long as it doesn't call the handful of blocking DOM APIs (such as alert() or
> sync XHR); we satisfy the current spec.
>

I don't understand why the sync XHR exception is taken so lightly.  As I
mention above, that is most frequently used as a
transparent-to-the-rest-of-the-application way of communicating with the
server (usually because some APIs cannot be easily changed or need to be
available during unload).  Yet, here we are saying that that cannot be
transparent because of this locking issue.



>
>
> The insidious part is that almost all the time, IE and Chrome will also be
> observed to obey the spec; when a quick cookie-read-modify-write script
> runs, it is very unlikely cookies will change underneath it. (Is it possible
> people don't write such scripts?)
>

I'm sure people write cookie-read-modify-write scripts and don't realize the
potential problems.  But I suspect the incidents of problems related to two
scripts doing so are extremely low as to not matter enough to application
developers.  They can just say:  opening our webmail program in two browser
tabs at the same time is not supported.



>
>
> Maybe we need dynamic race detection for Web browsers. After a script reads
> document.cookie, stall for a while to give network transactions or scripts
> running in other threads a chance to change the cookies so the original
> script carries on with wrong data.
>

Sounds interesting, but what happens when the script writes cookies?  Now
there is a merging problem :(

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