This came up today that I didn't remember having a conversation about it with
folks.
We currently have IDBDatabaseException with a some error codes as constants and
code/message properties. Looking at DOMException as defined in DOM Core [1], it
turns out that a) the pattern of the class is
I've created a bug to outline a potential change to the Sync API to handle the
context for setVersion transaction inside a callback method. I wanted to
follow up with the group to see what other people's thought about this change.
The Bug has all the details for the proposed change. The bug#
(This time before the deadline :)
Microsoft has the following additional feedback for this Last Call of Web
Workers.
We are concerned about the privacy implications we discovered when reviewing
the current web workers editor's draft in its treatment of shared workers [1].
Specifically, the
On Wed, Apr 20, 2011 at 12:47 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
(This time before the deadline :)
Microsoft has the following additional feedback for this Last Call of Web
Workers.
We are concerned about the privacy implications we discovered when reviewing
the
The open method description in the IDBFactory talks about setting the source of
the IDBRequest to no source. What does no source means (undefined,
null, other)?
In addition, what should be the value of the transaction property in the
IDBRequest object returned from the open method? It seems
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Please correct me if I'm missing something, but I don't see any new
privacy-leak vectors here. Without Shared Workers, 3rdparty.com can
just hold open a communication channel to its server and shuttle
information
On 4/20/2011 1:33 PM, Israel Hilerio wrote:
The open method description in the IDBFactory talks about setting the source of the IDBRequest to no
source. What does no source means (undefined, null, other)?
In addition, what should be the value of the transaction property in the IDBRequest
Hi All,
When a Blob is appended to a FormData, the XHR2 spec currently says
that the filename used should be the empty string unless the Blob is
also a File. If such a FormData is later submitted using
XMLHttpRequest, this will result in a request that contains something
similar to:
Actually, I think we should abandon codes entirely and use the new
mechanism that WebIDL uses.
I honestly have a bit of a hard time understanding the WebIDL spec,
but I believe the idea is to implement the proposal made in [1].
Basically rather than having .code we'd have .type, along with
Looks great to me. Remember that we need to make both .transaction and
.setVersion throw if called within the callback from either of them.
/ Jonas
On Mon, Apr 18, 2011 at 11:22 AM, Israel Hilerio isra...@microsoft.com wrote:
I've created a bug to outline a potential change to the Sync API to
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 20, 2011 at 12:47 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
(This time before the deadline :)
Microsoft has the following additional feedback for this Last Call of Web
Workers.
We are
On Wed, Apr 20, 2011 at 1:33 PM, Israel Hilerio isra...@microsoft.com wrote:
The open method description in the IDBFactory talks about setting the source
of the IDBRequest to no source. What does no source means (undefined,
null, other)?
In addition, what should be the value of the
On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Please correct me if I'm missing something, but I don't see any new
privacy-leak vectors here. Without Shared Workers, 3rdparty.com can
just hold
On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Please correct me if I'm missing something, but I don't see any new
On Wed, Apr 20, 2011 at 3:41 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 20, 2011 at 12:54 PM, Tab Atkins Jr. jackalm...@gmail.com
On Wed, Apr 20, 2011 at 3:57 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 20, 2011 at 3:41 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 20, 2011 at 3:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 20, 2011 at 3:13 PM, Jonas Sicking jo...@sicking.cc wrote:
First, thanks to Art for pulling all this content together. We're looking
forward to a more structured process for testing as various specifications
in the WebApps increase in maturity.
I have a couple of small comments related to the issues Aryeh raised.
Apologies for the lateness of these
On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking jo...@sicking.cc wrote:
That's why we're working on trying to fix fingerprinting.
The point is that privacy is something that we're all working on
trying to improve (right?), and the WebWorkers spec needs to be
changed to aid with that. As far
On Wed, Apr 20, 2011 at 5:58 PM, Andrew Wilson atwil...@google.com wrote:
On Wed, Apr 20, 2011 at 4:05 PM, Jonas Sicking jo...@sicking.cc wrote:
That's why we're working on trying to fix fingerprinting.
The point is that privacy is something that we're all working on
trying to improve
On 4/20/11 3:54 PM, Tab Atkins Jr. wrote:
Please correct me if I'm missing something, but I don't see any new
privacy-leak vectors here. Without Shared Workers, 3rdparty.com can
just hold open a communication channel to its server
Unless you have a firewall or proxy that prevents that
On 4/20/11 6:57 PM, Tab Atkins Jr. wrote:
True, you need some side-channel to link the two iframes for a
particular client. You can use something simple like one of the
*other* within-domain communication mediums (cookies, localStorage,
etc.)
Which is why there are options to restrict
On Tue, Apr 19, 2011 at 6:41 PM, Eliot Graff eliot.gr...@microsoft.com wrote:
Thanks for the feedback. Moving forward, I will track changes and resolution
of these suggestions in bug 9379 [1].
ok
Appreciate the time you've spent on this.
here's next next part, note that i drafted it a while
On Wed, 20 Apr 2011, Travis Leithead wrote:
We are concerned about the privacy implications we discovered when
reviewing the current web workers editor's draft in its treatment of
shared workers [1]. Specifically, the spec as currently written allows
for 3rd party content to use shared
23 matches
Mail list logo
