On Sun, Aug 30, 2009 at 4:06 AM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
If getStorageUpdates() actually returned how *many* updates there
were, it could be a vaguely useful name.
If the answer is 0, then my
I think the canonical racy case is the page wants to keep a counter for the
number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible to achieve this without the mutex - the
proposal below would break down if two pages tried to increment the cookie
value
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/1/09 7:31 PM, Jeremy Orlow wrote:
Does the silence mean that no one has any intention of implementing
this? If so, maybe we should resign ourselves to a break in the single
threaded illusion for cookies. This doesn't seem too outlandish
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/3/09 4:24 PM, Drew Wilson wrote:
I think the canonical racy case is the page wants to keep a counter for
the number of times event X occurs in a cookie or local storage.
Is it important that continue to work without racing? I don't think it's
On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedbergbenja...@smedbergs.us wrote:
* When the script sets document.cookie, it calculates the delta with the
original data and commit the changes.
What if there's a conflict with other changes that happened in the meantime?
On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg bsmedb...@mozilla.comwrote:
On 9/3/09 4:24 PM, Drew Wilson wrote:
I think the canonical racy case is the page wants to keep a counter for
the number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/3/09 5:06 PM, Aryeh Gregor wrote:
On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedbergbenja...@smedbergs.us
wrote:
* When the script sets document.cookie, it calculates the delta with the
original data and commit the changes.
What if there's
On Fri, Sep 4, 2009 at 8:17 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
What kind of conflict? There is no need to merge individual cookies:
whichever one was set (or removed) last wins.
I think this strategy would work fine for cookies since the HTTP side of
them is inherently racy. I
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
I do agree with Jeremy that we should rethink the spec language around
cookie consistency to reflect what
On Fri, Sep 4, 2009 at 10:25 AM, Drew Wilson atwil...@google.com wrote:
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
And to be clear: I don't have
On Fri, Sep 4, 2009 at 2:24 AM, timeless timel...@gmail.com wrote:
On Sun, Aug 30, 2009 at 4:06 AM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
If getStorageUpdates() actually returned how *many* updates there
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers to
use the more difficult database api for all storage needs, and to roll their
own change event mechanisms (based on postMessage). Thats a bunch of busy
work if a name/value pair
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult database api for all storage needs, and to roll
their own change event
On Fri, Sep 4, 2009 at 10:59 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult
On Tue, Sep 1, 2009 at 4:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow
When we had this discussion last, there was significant pushback on this -
the argument was basically we have no evidence that cookie-based race
conditions *aren't* causing sporadic breakages, which is true. It's
inherently difficult to measure.
As an aside, I'll note that the majority of pushback
On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow jor...@chromium.orgwrote:
Is there any data (or any way to collect the data) on how much of
On Wed, Sep 2, 2009 at 11:31 AM, Jeremy Orlow jor...@chromium.org wrote:
Does the silence mean that no one has any intention of implementing this?
I'm silent because I'm not currently working on this stuff so I can't say
what our plans are. But I'll be upset if I find out our plans are to
Jonas Sicking wrote:
On Sat, Aug 29, 2009 at 10:06 PM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
I really liked Darin's (?) suggestion of allowStorageUpdates as that
seems to exactly describe the intended use
'Commit' implies that it hasn't been committed yet, which is not true. This
will be misleading to those developers that do understand the locking
semantics (and transactional semantics) and are looking to defeat them. With
the 'commit' naming, we'd be doing a diservice to exactly the sort of
On Tue, 18 Aug 2009, Jeremy Orlow wrote:
First of all, I was wondering why all user prompts are specified as
must release the storage mutex (
http://dev.w3.org/html5/spec/Overview.html#user-prompts).
This is because otherwise, if the script has the storage mutex, the user
can't open any
On Fri, Aug 28, 2009 at 3:36 PM, Jeremy Orlowjor...@chromium.org wrote:
Can a plugin ever call into a script while a script is running besides when
the script is making a synchronous call to the plugin? If so, that worries
me since it'd be a way for the script to lose its lock at _any_ time.
On Tue, Aug 25, 2009 at 10:36 PM, Jeremy Orlowjor...@chromium.org wrote:
On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org
wrote:
To me, getStorageUpdates seems to imply that updates have
On Sun, Aug 23, 2009 at 1:22 AM, Jeremy Orlowjor...@chromium.org wrote:
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org wrote:
Lastly, is navigator.getStorageUpdates() the right name for the function
that drops the lock? Why was it changed from navigator.releaseLock()? I
On Fri, Aug 28, 2009 at 4:05 AM, Kevin Benson kevin.m.ben...@gmail.comwrote:
On Sun, Aug 23, 2009 at 1:22 AM, Jeremy Orlowjor...@chromium.org wrote:
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org
wrote:
Lastly, is navigator.getStorageUpdates() the right name for the
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
That behaviour sounds worse than what Firefox currently does, where an
alert disables input to all tabs in the window (which is already
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
That behaviour sounds worse than what Firefox currently does,
On Wed, Aug 26, 2009 at 12:49 AM, Darin Fisher da...@google.com wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
But getStorageUpdates is still not the right name for it. The
I know that one of the design issues with worker threads and local
storage has been how to resolve concurrency issues, and that for this
reason, in the current spec worker threads can't access local storage.
However, there's a scenario under the current spec that doesn't
involve local
My recollection is that we prohibit worker access to cookies for exactly
this reason (WorkerGlobalScope does not expose a cookies attribute).
-atw
On Wed, Aug 26, 2009 at 2:05 PM, Jens Alfke s...@google.com wrote:
I know that one of the design issues with worker threads and local storage
has
On Aug 26, 2009, at 2:11 PM, Drew Wilson wrote:
My recollection is that we prohibit worker access to cookies for
exactly this reason (WorkerGlobalScope does not expose a cookies
attribute).
Looks like you're right; section 5 of the Web Workers spec says:
The DOM APIs (Node objects,
We discussed this in more detail here:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg13799.html
At the time, I suggested not protecting cookies with a mutex (allow
asynchronous access - the current behavior on IE and Chrome), which made the
monocles pop out of everyone's eyes :)
-atw
Is there any data (or any way to collect the data) on how much of the web IE
and Chrome's current behavior has broken? Given that there hasn't been
panic in the streets, I'm assuming approximately 0%?
Given that web developers have never had any guarantees for cookie
access/setting in terms of
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow jor...@chromium.org wrote:
Is there any data (or any way to collect the data) on how much of the web
IE and Chrome's current behavior has broken? Given that there
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org wrote:
To me, getStorageUpdates seems to imply that updates have already happened
and we're working with an old version of the data. I think many developers
will be quite shocked that getStorageUpdates _enables_ others to
On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.orgwrote:
To me, getStorageUpdates seems to imply that updates have already happened
and we're working with an old version of the data. I think many
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.orgwrote:
First of all, I was wondering why all user prompts are specified
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow jor...@chromium.org wrote:
First of all, I was wondering why all user prompts are specified as must
release the storage mutex (
http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this
really say must instead of may? IIRC (I
On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow jor...@chromium.org wrote:
It's also worth noting that Chromium is probably going to need to drop the
storage mutex for most if not all plugin related calls due to deadlock
conditions. If there were some place to mention this as a may type thing,
I was looking through the WebStorage and HTML 5 specs regarding the storage
mutex. I have a few comments/questions.
First of all, I was wondering why all user prompts are specified as must
release the storage mutex (
http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this
really
44 matches
Mail list logo
