Looks like the WorkerGlobalScope_ErrorEvent_*.htm tests are still in error
as mentioned below.
dave
On Tue, Sep 20, 2011 at 10:53 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> Thanks! We’ll see about getting these updated…
>
> ** **
>
> *From:* D
What is the backwards compatibility story for websites already using
SharedWorkers with the interface that has been in the spec for over a year
now?
There are sites using them. For example, Google Docs uses them and Google
Web Toolkit exposes them.
dave
It seems like this may be setting up a pattern for other dom objects which
are large (like video/audio).
When applied in this context, is "close" still a good verb for them?
video.close();
dave
PS I'm trying to not bikeshed too badly by avoiding a new name suggestion
and allowing for the fact
On Fri, Nov 18, 2011 at 9:07 AM, Glenn Maynard wrote:
> On Fri, Nov 18, 2011 at 11:50 AM, David Levin wrote:
>
>> So the primary use case is code in the worker which has no other (async)
>> messages coming in?
>>
>
> No--you can always create another mess
On Fri, Nov 18, 2011 at 8:16 AM, Glenn Maynard wrote:
> On Thu, Nov 17, 2011 at 10:33 PM, David Levin wrote:
>
>> Ah so the proposal is really only adding a new method only
>> on DedicatedWorkerGlobalScope which send a synchronous message and
>> something correspon
On Thu, Nov 17, 2011 at 6:41 PM, Jonas Sicking wrote:
> On Thu, Nov 17, 2011 at 6:05 PM, David Levin wrote:
> >
> >
> > On Thu, Nov 17, 2011 at 5:05 PM, Jonas Sicking wrote:
> >>
> >> On Thu, Nov 17, 2011 at 2:07 PM, David Levin
> wrote:
> >&
On Thu, Nov 17, 2011 at 5:05 PM, Jonas Sicking wrote:
> On Thu, Nov 17, 2011 at 2:07 PM, David Levin wrote:
> > It seems like this mechanism would deadlock a worker if two workers send
> > each other a synchronous message.
>
> Indeed. We can only allow child workers to bl
It seems like this mechanism would deadlock a worker if two workers send
each other a synchronous message.
dave
On Thu, Nov 17, 2011 at 10:37 AM, Joshua Bell wrote:
> Jonas and I were having an offline discussing regarding the synchronous
> Indexed Database API and noting how clean and straigh
On Tue, Sep 13, 2011 at 6:26 PM, Adrian Bateman wrote:
>
> WebWorkers (51 tests/assertions)
> Changeset: http://dvcs.w3.org/hg/webapps/rev/7b0ba70f69b6
> Tests: http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/
> * We believe the tests are all accurate but look forward to wider r
On Mon, Feb 14, 2011 at 2:18 AM, Ian Hickson wrote:
> On Sat, 12 Feb 2011, Arthur Barstow wrote:
> >
> > Regarding re-publishing the Web Workers spec [ED] as a new Last Call
> > Working Draft ...
> >
> > Bugzilla shows one open bug [Bugs]:
> >
> > 11818 - As documented in the "Creating workers"
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 4:33 AM, David Levin wrote:
>
>> Making people use a helper function like that is just making them jump an
>>> unnecessary hoop.
>>>
>>
>> It makes them jump through
On Wed, Jun 22, 2011 at 12:26 AM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 3:14 AM, David Levin wrote:
>
>> On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard wrote:
>>
>>> On Wed, Jun 22, 2011 at 1:57 AM, David Levin wrote:
>>>
>>>> Let&
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 1:57 AM, David Levin wrote:
>
>> Let's say the call doesn't throw when given a type B that isn't
>> transferrable.
>> Let's also say some later changes the javascript c
On Tue, Jun 21, 2011 at 10:48 PM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 1:25 AM, David Levin wrote:
>
>> On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard wrote:
>>
>>> What happens if an object is included in the second list that doesn't
>>>
On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard wrote:
> What happens if an object is included in the second list that doesn't
> support transfer? Ian said that it would throw, but I'm not sure that's
> best.
>
If it doesn't throw, doesn't that introduce the backwards compat issue when
something
On Fri, Jun 10, 2011 at 12:50 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
>
>
> >From: Kenneth Russell [mailto:k...@google.com], Sent: Thursday, June 09,
> 2011 11:15 PM
> >On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
> > wrote:
> >> Honestly, there's something about this whole
ok.
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell wrote:
> On Wed, Jun 8, 2011 at 2:39 PM, David Levin wrote:
> >
> >
> > On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote:
> >>
> >> I prefer continuing to use an array for several reasons: simpl
>
> On Wed, Jun 8, 2011 at 2:29 PM, David Levin wrote:
> >
> >
> > On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell wrote:
> >>
> >> My understanding is that we have reached a proposal which respecifies
> >> the "ports" argument to pos
On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell wrote:
> My understanding is that we have reached a proposal which respecifies
> the "ports" argument to postMessage as an array of objects to
> transfer, in such a way that we:
>
Array or object? (by object I mean: {transfer: [arrayBuffer1], ports
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
> >> None of the objects which allow transferring of ownership has children
> >> so this doesn't appear to be a problem at this time. If it indeed does
> >
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
> >
> >
> > On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
> >> port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
> >> [port]})
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
> On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell wrote:
> > On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
> > The desire would be for this change to apply not just to the
> > postMessage method on MessagePort a
On Thu, Jun 2, 2011 at 1:13 PM, Boris Zbarsky wrote:
> On 6/2/11 3:53 PM, David Levin wrote:
>
>> The mechanism:
>>
>>* needs to have an intuitive feel for developers,
>>* must preserve backwards compatibility,
>>* should ideally allow the por
In summary, there is a desire for a mechanism to transfer objects (to allow
for potentially better perf) across a MessagePort.
The mechanism:
- needs to have an intuitive feel for developers,
- must preserve backwards compatibility,
- should ideally allow the port to function the same re
fwiw, specifying up front is what FileReader appears to do:
http://dev.w3.org/2006/webapi/FileAPI/#dfn-filereader
Of course, there are different methods in that case.
dave
On Tue, Sep 28, 2010 at 3:12 PM, Chris Rogers wrote:
> Based on these constraints, it sounds like we either have to live wi
On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman wrote:
> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote:
> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin wrote:
> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman
> > wrote:
> > I read point #5 to be only abo
On Tue, Jul 13, 2010 at 12:48 AM, Anne van Kesteren wrote:
> On Mon, 12 Jul 2010 23:30:54 +0200, Darin Fisher
> wrote:
>
>> Right, it seems reasonable to say that ownership of the resource
>> referenced by a Blob can be shared by a XHR, Image, or navigation once it is
>> told to
>> start loading
On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman wrote:
> On Monday, July 12, 2010 9:32 AM, David Levin wrote:
> > On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman
> > wrote:
> > The behaviour would have to be explicitly specified and not left to
> depend on
&
On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman wrote:
> On Monday, July 12, 2010 8:24 AM, David Levin wrote:
> > On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman
> > wrote:
> > > Making the blob url identical to the lifetime of the blob itself would
> > > exp
On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman wrote:
>
> > Making the blob url identical to the lifetime of the blob itself would
> > expose when garbage collection takes place and in general could lead to
> > easy to make mistakes in which the developer had something that work
> > mostly but not
On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman wrote:
> On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote:
> > On 6/23/10 9:50 AM, Jian Li wrote:
> > I think encoding the security origin in the URL allows the UAs to do
> > the security origin check in place, without routing through other
On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman wrote:
> On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
> > I agree with you Adrian that it makes sense to let the user agent figure
> > out the optimal way of implementing origin and other checks.
> >
> > A logica
On Tue, Jun 22, 2010 at 7:58 PM, Adrian Bateman wrote:
> On Tuesday, June 22, 2010 3:37 PM, Arun Ranganathan wrote:
> > On 6/22/10 8:44 AM, Adrian Bateman wrote:
> > > I think it makes more sense for the URL to be opaque and let user
> > > agents figure
> > > out the optimal way of implementing or
On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan wrote:
> Greetings WebApps WG,
>
> I have updated the editor's draft of the File API to reflect changes that
> have been in discussion.
>
> http://dev.w3.org/2006/webapi/FileAPI
>
> Notably:
>
> 1. Blobs now allow further binary data operations by
What about using a filename that is unique with repect to files sent in that
FormData (but it is up to the UA)? For example, a UA may choose to do Blob1,
Blob2, etc. For the content-type, application/octet-string seems most
fitting.
Here's the result applied to your example:
--SomeBoundary.
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen wrote:
> FWIW, Microsoft explicitly says notifications must be ignorable and don't
> persist. "Notifications aren't modal and don't require user interaction, so
> users can freely ignore them." "In Windows Vista® and later, notifications
> are displa
On Fri, Feb 5, 2010 at 6:52 AM, Anne van Kesteren wrote:
> On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg wrote:
>
>> In the case the first notification from an application is an important
>> one,
>> that app should be able to request permission for out-of-tab notifications
>> beforehand;
>>
>
>
It appears that both Safari and Firefox ignore returned cookies from a cross
origin xhr when the credentials flag is set to false. This behavior seems
very reasonable.
Should the XMLHttpRequest level 2 spec indicate that this is the expected
behavior?
Dave
On Thu, Jul 30, 2009 at 11:46 AM, David
In http://www.w3.org/TR/XMLHttpRequest2/#credentials, it
says: "The credentials flag takes the values true and false, true by
default..."
Both Firefox and Safari have defaulted the value to "False" but the spec
says the default is "True". Given that these are the two implementations
out there, it
In http://www.w3.org/TR/XMLHttpRequest2/#credentials, it
says: "The credentials flag ...indicates whether a non same origin request
includes cookie and HTTP authentication data...during the send() algorithm."
If withCredentials is false, it seems like the cookies returned from the
request shouldn'
Yes, all is good. Sorry for the false alarm.
On Thu, Feb 26, 2009 at 1:54 AM, Anne van Kesteren wrote:
> On Wed, 25 Feb 2009 14:34:19 +0900, David Levin
> wrote:
>
>> Just to round out the thread :), I fixed my test for IE and found that
>> IE7 also throws an exception in
Regarding the http redirect security violation steps, the spec (
http://dev.w3.org/2006/webapi/XMLHttpRequest/) says "If async is set to
false raise a NETWORK_ERR exception and terminate the overall algorithm."
I tried out IE7, Firefox 3, and WebKit nightlies and none of them seem to
throw an excep
Just to round out the thread :), I fixed my test for IE and found that IE7
also throws an exception in this case.
On Tue, Feb 24, 2009 at 2:23 PM, David Levin wrote:
> I just got a Firefox nightly and found that it does throw in this case, so
> the behavior changed from FF 3.
> Also,
43 matches
Mail list logo
