Thanks for the info - I wasn't aware of the new Ubuntu notification
infrastructure. Notes below:
On Mon, Mar 9, 2009 at 10:42 PM, Matthew Paul Thomas m...@myrealbox.comwrote:
Speaking for Ubuntu, we are making active efforts to reduce the number
of elements in the notification area (aka
On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking jo...@sicking.cc wrote:
However a much more interesting question is if sites would break if
the above stopped being true. That is most definitely the case.
Agreed - existing behavior trumps spec ambiguity. However, in this case I
was assuming
On Mon, Mar 9, 2009 at 10:23 AM, Jonas Sicking jo...@sicking.cc wrote:
The problem is that people are likely to write code like:
if (self.getAllCookies() != magic value) {
a = self.getAllCookies();
...do stuff...
}
at that point it's entirely possible for 'a' to have the value magic
() {
for (var i = 0 ; i 1 ; i++) {
document.cookie = (cookieSetVal= + i);
}
setTimeout(cookieSet, 0);
document.getElementById('log').innerHTML = count++;
};
/script
/body
/html
On Mon, Mar 9, 2009 at 11:38 AM, Drew Wilson atwil...@google.com wrote:
On Mon, Mar
and most important
3) why it did actually happen in my code? (using an async XHR)
Not sure what you are saying here. Do you have example code.
I think what he's talking about the issue described at
http://www.nerdgod.com/ie7test2.html.
I was CC'd on an email thread about this last year
document.cookies can't change in the middle of an execution. I.e. a script
like:
a = document.cookie;
b = document.cookie;
alert(a === b);
will always show 'true'.
Is that strictly true? Can you point me to the appropriate part of the spec,
because I couldn't find anything relevant
My team at Google is experimenting with supporting persistent SharedWorkers
(SharedWorkers whose lifetime is not linked to being entangled with an
active browser window). I've reviewed some of the mailing list archives, so
I'm aware of at least some of the past discussions on this topic - I wanted
at the thought of trying to define cross-browser extension
behavior. But I do agree that sharing some of the install/management UI
probably makes sense.
-atw
On Fri, Mar 6, 2009 at 2:11 PM, Martin Atkins m...@degeneration.co.ukwrote:
Drew Wilson wrote:
- Permissions:
Installing a persistent worker
Hi all,
There's currently no way to set or get cookies from workers, which makes
various types of cookie-based operations problematic.
I'd like to suggest that we add an API to workers to support this, via a
cookie attribute on the WorkerGlobalScope interface. This cookie attribute
would act
So an asynchronous cookie setting API would look like:
setCookie(cookieStr, callback)
...where the callback is invoked once the cookie has been set?
I guess I don't yet entirely understand the implementation details - it
sounds like there are problems accessing any shared state between workers
In my particular case, I'm trying to figure out how to use cookie-based
authentication from workers.
I could use postMessage() to a main window to set cookies. However, I have
another motivation for exploring this: my team is planning to experiment
with persistent workers (workers that continue
be depending on the value of
document.cookie being static anyway.
-atw
On Thu, Mar 5, 2009 at 5:55 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Mar 5, 2009 at 5:44 PM, Drew Wilson atwil...@google.com wrote:
So an asynchronous cookie setting API would look like:
setCookie(cookieStr, callback
postMessage()? :-)
I'm still wondering if we're just trying to ensure behavior (allowing JS
code to access the cookies without having them change asynchronously) that
the spec fundamentally doesn't guarantee anyway.
-atw
101 - 113 of 113 matches
Mail list logo
