If you call cloneNode on a media element, the state of the resulting media
element seems unspecified. Should it be playing the same media resource at
the same current time as the original?
Similar questions arise when you clone form elements; is the state that's
not visible in the DOM cloned?
Who
On Wed, Sep 9, 2009 at 10:12 PM, Aaron Boodman wrote:
> On Wed, Sep 9, 2009 at 10:07 PM, Darin Fisher wrote:
> > Well, the problem is that the creator of the transaction and the code
> > associated with the showModalDialog call may not be related. The
> > showModalDialog code might normally be u
On Wed, Sep 9, 2009 at 10:07 PM, Darin Fisher wrote:
> Well, the problem is that the creator of the transaction and the code
> associated with the showModalDialog call may not be related. The
> showModalDialog code might normally be used outside the context of a
> transaction, in which case the co
On Thu, Sep 10, 2009 at 4:57 PM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 9:43 PM, Robert O'Callahan wrote:
>
>> On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher wrote:
>>
>>> Imagine if you script a plugin inside the transaction, and before
>>> returning, the plugin scripts another window,
>>
On Wed, Sep 9, 2009 at 10:03 PM, Aaron Boodman wrote:
> On Wed, Sep 9, 2009 at 9:13 PM, Darin Fisher wrote:
> > If I call showModalDialog from within a database transaction, and then
> > showModalDialog
> > tries to create another database transaction, should I expect that the
> > transaction
> >
On Wed, Sep 9, 2009 at 10:01 PM, Robert O'Callahan wrote:
> On Thu, Sep 10, 2009 at 4:57 PM, Darin Fisher wrote:
>
>> On Wed, Sep 9, 2009 at 9:43 PM, Robert O'Callahan
>> wrote:
>>
>>> On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher wrote:
>>>
Imagine if you script a plugin inside the transa
On Wed, Sep 9, 2009 at 9:13 PM, Darin Fisher wrote:
> If I call showModalDialog from within a database transaction, and then
> showModalDialog
> tries to create another database transaction, should I expect that the
> transaction
> can be started within the nested run loop of the modal dialog?
By
On Wed, Sep 9, 2009 at 9:43 PM, Robert O'Callahan wrote:
> On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher wrote:
>
>> Imagine if you script a plugin inside the transaction, and before
>> returning, the plugin scripts another window,
>>
>
> I'm curious, how common is that anyway? Can we just tell
On Wed, Sep 9, 2009 at 9:28 PM, Robert O'Callahan wrote:
> On Thu, Sep 10, 2009 at 4:11 PM, Darin Fisher wrote:
>
>> On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan
>> wrote:
>>
>>> On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher wrote:
>>>
What concerns me are the cases where synchronous e
On Thu, Sep 10, 2009 at 1:37 PM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 9:27 PM, Jeremy Orlow wrote:
>
>> On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher wrote:
>>
>>> On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman wrote:
>>>
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman wrote:
>
On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher wrote:
> Imagine if you script a plugin inside the transaction, and before
> returning, the plugin scripts another window,
>
I'm curious, how common is that anyway? Can we just tell plugins not to do
that, and abort any plugin that tries?
Rob
--
"
On Wed, Sep 9, 2009 at 9:27 PM, Jeremy Orlow wrote:
> On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher wrote:
>
>> On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman wrote:
>>
>>> On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman wrote:
>>> > I see.
>>> >
>>> > So you are suggesting the localStorage could
On Thu, Sep 10, 2009 at 4:11 PM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan wrote:
>
>> On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher wrote:
>>
>>> What concerns me are the cases where synchronous events (e.g., resizing
>>> an iframe) can cause script to execute in a
On Thu, Sep 10, 2009 at 1:13 PM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman wrote:
>
>> On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman wrote:
>> > I see.
>> >
>> > So you are suggesting the localStorage could have zero concurrency
>> > guarantees and it is simply up to t
On Wed, Sep 9, 2009 at 6:46 PM, Aaron Boodman wrote:
> On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman 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
> > themselves using this new pr
On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan wrote:
> On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher 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 w
On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher 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
On Wed, Sep 9, 2009 at 4:24 PM, Robert O'Callahan wrote:
> On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher wrote:
>
>> Yes, exactly. Sorry for not making this clear. I believe implicit locking
>> for LocalStorage (and the implicit unlocking) is going to yield something
>> very confusing and hard t
On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman wrote:
> If this feature existed, we likely would have used it for offline Gmail to
> coordinate which instance of the app (page with gmail in it) should be
> responsible for sync'ing the local database with the mail service. In the
> absence of a f
On Thu, Sep 10, 2009 at 1:33 PM, Jeremy Orlow wrote:
> In general this seems like a pretty interesting idea. It definitely would
> be nice to completely abstract away all concepts of concurrency from web
> developers, but some of our solutions thus far (message passing, async
> interfaces, etc)
If this feature existed, we likely would have used it for offline Gmail to
coordinate which instance of the app (page with gmail in it) should be
responsible for sync'ing the local database with the mail service. In the
absence of a feature like this, instead we used the local database itself to
re
On Sep 9, 2009, at 6:33 PM, Jeremy Orlow wrote:
In general this seems like a pretty interesting idea. It definitely
would be nice to completely abstract away all concepts of
concurrency from web developers, but some of our solutions thus far
(message passing, async interfaces, etc) have n
On Thu, Sep 10, 2009 at 1:59 AM, Chris Jones wrote:
> Jeremy Orlow wrote:
>
>> What failures could there be in a pesimistic/queue model?
>>
>
> I'm trying to think of a "universal failure," something that could arise in
> any implementation of any proposal. I think that universal failure is
> "e
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman 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
> themselves using this new primitive.
>
> That is an interesting idea. You're right that it over
In general this seems like a pretty interesting idea. It definitely would
be nice to completely abstract away all concepts of concurrency from web
developers, but some of our solutions thus far (message passing, async
interfaces, etc) have not been terribly appreciated by developers either.
The G
On 9/10/09 2:24 AM, Robert O'Callahan wrote:
On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher mailto: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 something very conf
On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher wrote:
> Yes, exactly. Sorry for not making this clear. I believe implicit locking
> for LocalStorage (and the implicit unlocking) is going to yield something
> very confusing and hard to implement well. The potential for dead locks
> when you fail
On Wed, Sep 9, 2009 at 3:37 PM, Maciej Stachowiak 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,
>> we
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, we should give web apps the tools to manage exclusive
access to shared
On Wed, Sep 9, 2009 at 11:30 AM, Aaron Boodman wrote:
> On Wed, Sep 9, 2009 at 11:23 AM, Darin Fisher wrote:
> > On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman wrote:
> >> There would presumably have to be a separate name value for each API,
> >> though, right? So we're talking about the differe
On Wed, Sep 9, 2009 at 11:23 AM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman wrote:
>> There would presumably have to be a separate name value for each API,
>> though, right? So we're talking about the difference between:
>>
>> window.acquireLock("localStorage", function()
On Wed, Sep 9, 2009 at 11:08 AM, Aaron Boodman wrote:
> On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisher 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
> frame) locks on the
On Wed, Sep 9, 2009 at 10:55 AM, Darin Fisher 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
frame) locks on the types of things we've been discussing (local
storage, databases, etc)
+1, a nice refactoring of the implied locking gunk in the storage api.
On Wed, 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
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:
window.acqui
On Sep 4, 2009, at 2:38 PM, Ian Hickson wrote:
Right. My point is the site can do that already, since we don't ever
_stop_ the site from using the local storage area. It can prompt you
for
a name directly, without UA involvement.
I'm sorry, I don't understand that. We must somehow be talki
Jeremy Orlow wrote:
Those who want a queue. I.e. those who want an asynchronous
callback based interface and the UA will only call one callback
at a time. Perhaps on a per-origin basis. Note that this can
never "fail", need to be rolled back, etc.
This sou
Anne van Kesteren wrote:
> On Tue, 08 Sep 2009 21:40:22 +0200, NARUSE, Yui wrote:
>> First is about 4.10.16.4 URL-encoded form data.
>> http://www.whatwg.org/specs/web-apps/current-work/#application/x-www-form-urlencoded-encoding-algorithm
>>
>>
>> In this algorithm at 6.2.1,
>> "SP, *, -, ., 0 ..
On Tue, 08 Sep 2009 21:40:22 +0200, NARUSE, Yui wrote:
First is about 4.10.16.4 URL-encoded form data.
http://www.whatwg.org/specs/web-apps/current-work/#application/x-www-form-urlencoded-encoding-algorithm
In this algorithm at 6.2.1,
"SP, *, -, ., 0 .. 9, A .. Z, _, a .. z" is not escaped.
But
On 8 Sep 2009, at 23:39, I wrote:
UTF-16BE
Actually, endianness is immaterial. Please read this as "UTF-16"
instead.
Sorry for the extra message.
--
Øistein E. Andersen
Great analysis. I only have a few comments/questions:
On Wed, Sep 9, 2009 at 1:41 PM, Chris Jones wrote:
> Jeremy Orlow wrote:
>
>> On Wed, Sep 9, 2009 at 4:39 AM, Chris Jones > cjo...@mozilla.com>> wrote:
>>
>>Aaron Boodman wrote:
>>
>>On Tue, Sep 8, 2009 at 11:23 AM, Chris Jones>
41 matches
Mail list logo
