On Tue, Apr 17, 2012 at 9:12 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/17/12 6:32 PM, Darin Fisher wrote:
In Chrome at least, getImageData() doesn't actually block to fetch pixels.
The thread is only blocked when the first dereference of the pixel buffer
occurs.
How does
On Sun, Apr 22, 2012 at 6:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2012, at 6:53 AM, Glenn Maynard wrote:
On Thu, Apr 19, 2012 at 11:28 PM, Maciej Stachowiak m...@apple.com wrote:
You could also address this by adding a way to be notified when the
contents of an ImageData
On Mon, Apr 16, 2012 at 4:05 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 2:57 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 2:34 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote
On Wed, Mar 21, 2012 at 8:29 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 20, 2012, at 12:00 PM, James Robinson wrote:
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many optimization
opportunities that are
On Mon, Apr 16, 2012 at 11:17 AM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote:
Carrots and Sticks.
Aren't we missing an opportunity here? By giving web developers this
easy
migration path, you're also giving up
Glenn summarizes my concerns exactly. Deferred rendering is indeed the
more precise issue.
On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote:
Could someone construct a demonstration of where the read back of the
imagedata takes longer than a runloop cycle?
I bet this
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user
On Mon, Apr 16, 2012 at 1:45 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote:
See synchronous XMLHttpRequest. I'm sure every browser vendor wishes
that
didn't exist. Note how we recently withdrew support for synchronous
On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote:
Glenn summarizes my concerns exactly. Deferred rendering is indeed the
more precise issue.
On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli
On Mon, Apr 16, 2012 at 2:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote:
On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote:
I don't understand why adding a runloop cycle to any read seems like
something that would
On Mon, Apr 16, 2012 at 2:57 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 2:34 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote:
Glenn
On Mon, Apr 16, 2012 at 2:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com
wrote:
Con: Encourages poor HI design (since these stock dialogs should almost
Can you hide this behind adoptNode just as we did for magic iframe? The
nice thing about adoptNode is that the browser gets told both the source and
destination parent nodes. This way there is never a disconnected state.
So long as we unload when moving between documents, we should be pretty
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal
version of window.confirm() or window.alert(). Dialogs that are fully
in-page
Oops, got cut off
On Thu, Mar 29, 2012 at 1:10 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal
version
On Tue, Mar 20, 2012 at 4:05 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Mar 19, 2012 at 3:38 PM, Jochen Eisinger joc...@chromium.org
wrote:
I'd like to put forward a proposal for extending the modal prompts
(alert/confirm/prompt) with an optional callback parameter. If the
optional
On Tue, Oct 18, 2011 at 9:40 PM, Anne van Kesteren ann...@opera.com wrote:
1) How much should UI-based and API-based fullscreen interact? To me it
seems nice if pressing F11 would also give you fullscreenchange events and
that Document.fullscreen would yield true. Why would you not want to
On Tue, Oct 18, 2011 at 7:24 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Oct 18, 2011 at 3:55 AM, Anne van Kesteren ann...@opera.com
wrote:
However, I just realized this does not work for the single document case.
You have a video player website and you host your videos in video or
Hi Anne,
Thanks for working on this spec! I have more questions, but I'll just start
with one. If enterFullscreen() is called when the browsing context is
already being displayed fullscreen, what should happen? (It looks like
Safari 5.1 ignores the second call to webkitRequestFullScreen.)
I
OK, I can't help myself. One more question:
What should happen if the fullscreen browsing context is navigated? What
happens if the document, containing the fullscreen element, is destroyed?
Perhaps it should bounce out of fullscreen mode?
-Darin
On Mon, Oct 17, 2011 at 3:55 PM, Darin
Putting implementation details aside, I agree that it is a bit unfortunate
to refer to a stream as a blob. So far, blobs have always referred to
static, fixed-size things.
This function was originally named createBlobURL, but it was renamed
createObjectURL precisely because we imagined it being
rel=anything makes me sad as it will mean more UA sniffing. The fallback
behavior of loading the href inline could be dangerous.
On Jul 15, 2011 5:38 PM, Tantek Çelik tan...@cs.stanford.edu wrote:
On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote:
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com:
2011/7/15 Jonas Sicking jo...@sicking.cc
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com:
Many websites wish to offer a file for download, even though it could
On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com
Many websites wish to offer a file for download, even though it could
potentially be viewed inline (take images, PDFs, or word documents as an
example). Traditionally the
On Thu, Jul 14, 2011 at 1:32 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
2011/7/14 Darin Fisher da...@chromium.org:
On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com
Many websites wish to offer a file for download
On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard gl...@zewt.org wrote:
2011/7/14 Darin Fisher da...@chromium.org
I know that there is also a proposal to add a FileSaver API. I like that
as well, _but_ it is very nice to be able to simply decorate an anchor tag.
In many cases
Case #1:
var f = document.createElement(iframe);
f.src = http://foo.com/;;
document.body.appendChild(f);
Case #2:
var f = document.createElement(iframe);
document.body.appendChild(f);
f.src = http://foo.com/;;
My interpretation of section 4.8.2 is that in case #1 the iframe should be
On Fri, Feb 26, 2010 at 10:56 AM, Diogo Resende drese...@thinkdigital.ptwrote:
What about something like:
document.pushCookies(function () {
// cookies have been pushed to the js process
var x = document.getCookie(x);
//
On Fri, Feb 26, 2010 at 12:04 PM, Diogo Resende drese...@thinkdigital.ptwrote:
No. pushCookies would be a way of pushing cookies to the
current js and
then you could call getCookie several times without defining a
callback.
It would be almost
On Thu, Feb 25, 2010 at 6:54 AM, Diogo Resende drese...@thinkdigital.ptwrote:
On Wed, 2010-02-24 at 11:21 -0800, Darin Fisher wrote:
For reference, reading document.cookie has measurable performance cost
in Chromium since the cookie jar lives in a process separate from the
process running
An explicit deleteCookie method might also be nice.
-Darin
On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth w...@adambarth.com wrote:
The document.cookie API is kind of terrible. Web developers shouldn't
have to parse a cookie-string or prepare a properly formated
set-cookie-string. Here's a
: My beliefs do not require them to.
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:
whatwg-boun...@lists.whatwg.org] On Behalf Of Adam Barth
Sent: Wednesday, February 24, 2010 8:47 AM
To: Darin Fisher
Cc: whatwg
Subject: Re: [whatwg] HTML Cookie API
Done.
On Wed
On Wed, Feb 24, 2010 at 6:08 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Feb 24, 2010 at 5:00 PM, Nicholas Zakas nza...@yahoo-inc.com
wrote:
Even though there can be multiple cookies with the same name on a single
document, this most frequently occurs due to error rather than intention.
On Mon, Feb 22, 2010 at 4:05 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking jo...@sicking.cc
wrote:
On Mon, Feb 22, 2010 at 11:13 AM, David Levin le...@google.com wrote:
I don't know... to me, asynchronous means completes later. Precedence:
XMLHttpRequest.
The Mozilla network code uses the phrase load background to describe a
load that happens asynchronously in the background _and_ does not block
onload. Perhaps not coincidentally, this mode is used to load
The thing is, almost all subresources load asynchronously. The load event
exists to tell us when those asynchronous loads have finished. So, I think
it follows that an asynchronous resource load may reasonably block the load
event. (That's the point of the load event afterall!)
-Darin
On
On Thu, Jan 28, 2010 at 6:42 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote:
We have been discussing a more general fullscreen API that lets you take
the page fullscreen (perhaps with the ability to focus on a single element),
On Wed, Jan 27, 2010 at 3:26 PM, Ian Hickson i...@hixie.ch wrote:
Another is what should happen if a page goes back() past its fragment
identifier entries, and then modifies the document or alerts the
location? What location should it get? Which document should it
mutate? (test 007)
On Fri, Jan 22, 2010 at 1:13 AM, Maciej Stachowiak m...@apple.com wrote:
On Jan 21, 2010, at 8:37 PM, Darin Fisher wrote:
On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak m...@apple.com wrote:
I asked Brady (the Safari/WebKit engineer who implemented pushState())
about this, and he told
On Fri, Jan 22, 2010 at 2:08 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 21 Jan 2010, Darin Fisher wrote:
In WebKit, history.back() is currently implemented asynchronously.
It's not clear to me what you mean by asynchronously.
Do you mean that the events fire asynchronously
In WebKit, history.back() is currently implemented asynchronously.
However, it was not always this way. Previously, if the back navigation
corresponded to a hash change, then the back navigation would complete
synchronously. If the back navigation corresponded to a different document,
then it
On Thu, Jan 21, 2010 at 3:18 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 1/21/10 11:12 AM, Darin Fisher wrote:
In WebKit, history.back() is currently implemented asynchronously.
However, it was not always this way. Previously, if the back navigation
corresponded to a hash change
On Thu, Jan 21, 2010 at 7:15 PM, Maciej Stachowiak m...@apple.com wrote:
On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:
In WebKit, history.back() is currently implemented asynchronously.
However, it was not always this way. Previously, if the back navigation
corresponded to a hash
On Thu, Jan 21, 2010 at 7:17 PM, Brady Eidson beid...@apple.com wrote:
On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:
In WebKit, history.back() is currently implemented asynchronously.
However, it was not always this way. Previously, if the back navigation
corresponded to a hash
On Thu, Jan 21, 2010 at 8:56 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 21, 2010 at 7:17 PM, Brady Eidson beid...@apple.com wrote:
On Jan 21, 2010, at 1:12 AM, Darin Fisher wrote:
In WebKit, history.back() is currently implemented asynchronously.
However, it was not always
On Thu, Jan 14, 2010 at 11:04 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 14 Jan 2010, Darin Fisher wrote:
On Thu, Jan 14, 2010 at 12:10 PM, David Levin le...@google.com wrote:
It seems like it the method should be toBlob.
This doesn't address my concern that you won't know
On Thu, Jan 14, 2010 at 12:10 PM, David Levin le...@google.com wrote:
It seems like it the method should be toBlob.
This doesn't address my concern that you won't know the mime type of
the blob returned.
This makes a good case to move the readonly attrbiute DOMString
type from File to
history entry is activated (6.10.3).
-Justin
On Tue, Jan 5, 2010 at 4:53 PM, Darin Fisher da...@chromium.org wrote:
I'd like to make sure that I'm understanding the spec for pushState and
the
popstate event properly.
Suppose, I have the following sequence of events:
1. Page A is loaded
://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#update-the-session-history-with-the-new-page
On Tue, Jan 12, 2010 at 3:54 PM, Darin Fisher da...@chromium.org wrote:
Hi,
I've been discussing this issue with Brady Eidson over
at https://bugs.webkit.org/show_bug.cgi?id=33224,
and his
On Wed, Jan 6, 2010 at 1:11 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 06 Jan 2010 06:30:17 +0100, Darin Fisher da...@chromium.org
wrote:
I suspect the postMessage would be dispatched in this case, but the event
dispatch would probably go to the document at http://a/ instead
I'd like to make sure that I'm understanding the spec for pushState and the
popstate event properly.
Suppose, I have the following sequence of events:
1. Page A is loaded.
2. Page A calls pushState(foo, null).
3. The user navigates to Page B.
4. The user navigates back to Page A (clicks the back
The window doesn't open synchronously, so you should have to wait for
http://x/ to load (or for its document to at least be created) before you
can start communicating with it.
Note: If you instead open about:blank you should be able to communicate
with it synchronously since about:blank is
On Tue, Jan 5, 2010 at 5:00 PM, Darin Fisher da...@chromium.org wrote:
The window doesn't open synchronously, so you should have to wait for
http://x/ to load (or for its document to at least be created) before
you
can start communicating with it.
Note: If you instead open about:blank you
to get it updated to reflect what implementors are doing.)
-Darin
https://bugs.webkit.org/show_bug.cgi?id=33160
On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher da...@chromium.org wrote:
[Apologies if this has been discussed before, but I couldn't find it in the
archives.]
Why does pushState only
[Apologies if this has been discussed before, but I couldn't find it in the
archives.]
Why does pushState only prune forward session history entries corresponding
to the same document? I would have expected it to behave like a reference
fragment navigation, which prunes *all* forward session
On Wed, Dec 16, 2009 at 12:06 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher da...@chromium.org wrote:
[Apologies if this has been discussed before, but I couldn't find it in
the
archives.]
Why does pushState only prune forward session history
On Wed, Nov 25, 2009 at 9:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/25/09 6:20 AM, Ian Hickson wrote:
- script calling a method implemented in native code on a host object
...
If this is a MUST, this seems like a possible compat issue depending on
whether the method is native
On Mon, Nov 2, 2009 at 3:46 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Nov 3, 2009 at 6:36 AM, Darin Fisher da...@chromium.org wrote:
1a) Given a page (domain A) containing an iframe (domain B), have the
outer page navigate the inner frame to about:blank. This navigation
On Mon, Nov 2, 2009 at 1:28 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sun, Nov 1, 2009 at 3:53 AM, Darin Fisher da...@chromium.org wrote:
On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher da
On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher da...@chromium.org wrote:
You are right that the conditions are specific, but I don't know that that
is the
exhaustive list. Rather than defining unlock points, I
Sep 2009, Darin Fisher wrote:
The current API exposes race conditions to the web. The implicit
dropping of the storage lock is that. In Chrome, we'll have to drop an
existing lock whenever a new lock is acquired. That can happen due to a
variety of really odd cases (usually related
On Sat, Oct 17, 2009 at 11:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote:
On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote:
...
On Thu, 15 Oct 2009, Darin Fisher wrote:
This is interesting since
On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote:
...
On Thu, 15 Oct 2009, Darin Fisher wrote:
This is interesting since documentURI is a read/write property:
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI
I assume that is a mistake. Does anyone
On Fri, Oct 2, 2009 at 8:08 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 30, 2009 at 10:11 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Sep 29, 2009 at 11:48 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 29, 2009 at 12:19 AM, Darin Fisher da...@chromium.org
wrote
On Fri, Oct 2, 2009 at 9:43 PM, Jonas Sicking jo...@sicking.cc wrote:
Moreover, there are other examples which have been discussed on
the
list. There are some DOM operations that can result in a frame
receiving
a DOM event synchronously. That can result in a nesting of
On Wed, Sep 30, 2009 at 1:36 AM, Jonas Sicking jo...@sicking.cc wrote:
There's two things that I don't understand about the 'async' attribute
on script elements:
First of all, why is the parser responsible for executing scripts on
the list of scripts that will execute asynchronously, as
On Wed, Sep 30, 2009 at 9:59 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 30, 2009 at 1:36 AM, Jonas Sicking jo...@sicking.cc wrote:
There's two things that I don't understand about the 'async' attribute
on script elements:
First of all, why is the parser responsible for executing
On Thu, Sep 24, 2009 at 11:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 24, 2009 at 9:04 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Sep 24, 2009 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher da...@chromium.org
wrote
On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org
On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org wrote:
On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org
wrote:
On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc
wrote
On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org wrote:
On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc
wrote:
On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org
wrote
On Thu, Sep 24, 2009 at 9:28 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Sep 25, 2009 at 5:52 AM, Darin Fisher da...@chromium.org wrote:
No, no... my point is that to the application developer, those explicit
points will appear quite implicit and mysterious. This is why I called
On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org wrote:
On
On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman micha...@google.comwrote:
If this
On Thu, Sep 10, 2009 at 1:08 PM, Oliver Hunt oli...@apple.com wrote:
On Sep 10, 2009, at 12:55 PM, Darin Fisher wrote:
On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
On Wed, Sep 9, 2009 at 7:55 PM, Robert
On Thu, Sep 10, 2009 at 2:38 PM, James Robinson jam...@google.com wrote:
On Thu, Sep 10, 2009 at 1:55 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Sep 10, 2009 at 1:08 PM, Oliver Hunt oli...@apple.com wrote:
On Sep 10, 2009, at 12:55 PM, Darin Fisher wrote:
On Thu, Sep 10, 2009
On Thu, Sep 10, 2009 at 4:59 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Sep 11, 2009 at 9:52 AM, Darin Fisher da...@chromium.org wrote:
I think there are good applications for setting a long-lived lock. We can
try to make it hard for people to create those locks
On Thu, Sep 10, 2009 at 5:28 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Sep 10, 2009 at 4:59 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Fri, Sep 11, 2009 at 9:52 AM, Darin Fisher da...@chromium.org wrote:
I think there are good applications for setting a long-lived lock
The recent discussion about the storage mutex for Cookies and LocalStorage
got me thinking
Perhaps instead of trying to build implicit locking into those features, we
should give web apps the tools to manage exclusive access to shared
resources.
I imagine a simple lock API:
On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman a...@google.com wrote:
On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisherda...@chromium.org wrote:
I imagine a simple lock API:
window.acquireLock(name)
window.releaseLock(name)
I do not think it is a good idea to allow long-lived (past a stack
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman a...@google.com wrote:
On Wed, Sep 9, 2009 at 11:23 AM, Darin Fisherda...@chromium.org wrote:
On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman a...@google.com wrote:
There would presumably have to be a separate name value for each API,
though,
On Wed, Sep 9, 2009 at 3:37 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 9, 2009, at 10:55 AM, Darin Fisher wrote:
The recent discussion about the storage mutex for Cookies and LocalStorage
got me thinking
Perhaps instead of trying to build implicit locking into those features
On Wed, Sep 9, 2009 at 4:24 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher da...@chromium.org wrote:
Yes, exactly. Sorry for not making this clear. I believe implicit locking
for LocalStorage (and the implicit unlocking) is going to yield
On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher da...@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
On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman a...@google.com wrote:
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodmana...@google.com wrote:
I see.
So you are suggesting the localStorage could have zero concurrency
guarantees and it is simply up to the developer to arrange things
On Wed, Sep 9, 2009 at 9:27 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman a...@google.com wrote:
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodmana...@google.com wrote:
I see
On Wed, Sep 9, 2009 at 9:28 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 4:11 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher da
On Wed, Sep 9, 2009 at 9:43 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher da...@chromium.org wrote:
Imagine if you script a plugin inside the transaction, and before
returning, the plugin scripts another window,
I'm curious, how common
On Wed, Sep 9, 2009 at 10:01 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 4:57 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 9, 2009 at 9:43 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher da
On Wed, Sep 9, 2009 at 10:03 PM, Aaron Boodman a...@google.com wrote:
On Wed, Sep 9, 2009 at 9:13 PM, Darin Fisherda...@chromium.org wrote:
If I call showModalDialog from within a database transaction, and then
showModalDialog
tries to create another database transaction, should I expect
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
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 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 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote
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
On Wed, Aug 26, 2009 at 12:54 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.orgwrote
I agree. Moreover, since a shared worker identified by a given name cannot
be navigated elsewhere, the name isn't all that synonymous with other
usages of names (e.g., window.open). At the very least, it would seem
helpful to scope the name to the URL to avoid the name conflict issue.
-Darin
On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 9:18 AM, James Robinson jam...@google.com wrote:
However, users can't usefully check the readyState to see if the WebSocket
is still open because there are not and cannot be any
synchronization
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote:
Forcing applications to build their own send/ack functionality would be
pretty tragic considering that WebSockets are built on top of TCP.
-
1 - 100 of 111 matches
Mail list logo
