[access-control]
Should Access-Control-Allow-Origin need to be domain specific ? Infosec has recommended us to use this header : Access-Control-Allow-Origin:http://domainA.mycompany.com,http//*. mycompany.com But I also own domain : http://domainB.mycompany.com So, if i just use Access-Control-Allow-Origin:http://*.mycompany.com Will this be enough ? or it needs to be domain specific ?
[editing] JavaScript implementation
Hi, I'm really benefiting from all the hard work here ( https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html) and I think it's a great subject to address. Specifically, I've really found the JavaScript implementation ( https://dvcs.w3.org/hg/editing/raw-file/tip/implementation.js) a much needed tool for in-browser editing. While working with that implementation, I noticed what I would call a bug. Specifically, line 2278 returns undefined for the strikethrough and underline commands, causing unnecessary span elements to wrap selections when executing some commands. I imagine either the relevantCssProperty for these two commands should be set to 'textDecoration' or perhaps there are implementation-specific issues and it should be set to null. I hope this is the correct channel to provide this feedback; I did not see a better-fitting place to comment on the page. -Michael
Re: [IndexedDB] Transaction ordering for readonly transactions
On Fri, Mar 7, 2014 at 5:24 PM, Jonas Sicking jo...@sicking.cc wrote: Hi all, Currently the IndexedDB spec has strict requirements around the ordering for readwrite transactions. The spec says: If multiple readwrite transactions are attempting to access the same object store (i.e. if they have overlapping scope), the transaction that was created first MUST be the transaction which gets access to the object store first However there is very little language about the order in which readonly transactions should run. Specifically, there is nothing that says that if a readonly transaction is created after a readwrite transaction, that the readonly transaction runs after the readwrite transaction. This is true even if the two transactions have overlapping scopes. Chrome apparently takes advantage of this and actually sometimes runs readonly transactions before a readwrite transaction, even if the readonly transaction was created after the readwrite transaction. That is correct. This means that a readonly transaction that's started after a readwrite transaction may or may not see the data that was written by the readwrite transaction. This does seem like a nice optimization. Especially for implementations that use MVCC since it means that it can run the readonly and the readwrite transaction in parallel. Another benefit is that a connection that's issuing a series of readonly transactions won't suddenly pause just because a different connection in another page is starting a readwrite transaction. However I think the result is a bit confusing. I'm not so much worried that the fact that people will get callbacks in a different order matters. Even though in theory those callbacks could have sideeffects that will now happen in a different order. The more concerning thing is that the page will see different data in the database. One example of confusion is in this github thread: https://github.com/js-platform/filer/issues/128#issuecomment-36633317 This is a library which implements a filesystem API on top of IDB. Due to this optimization, writing a file and then checking if it exists may or may not succeed depending on if the transactions got reordered or not. And we (Chrome) have also had developer feedback that allowing readonly transactions to slip ahead' of busy/blocked readwrite transactions is surprising. That said, developers (1) have been quick to understand that implicit transaction ordering should be made explicit by not creating dependent transactions until the previous one has actually completed - and probably fixing some application logic bugs at the same time, and (2) have taken advantage of readonly transactions not blocking on readwrite transactions, achieving much higher throughput without implementing their own data caching layer. So I'm definitely of two minds here. Removing this optimization will help developers in simple cases, but would hinder larger scale web apps. Other opinions? I'd like to strengthen the default ordering requirements and say that two transactions must run in the order they were created if they have overlapping scopes and either of them is a readwrite transaction. But I'd be totally open to adding some syntax to opt in to more flexible transaction ordering. Possibly by introducing a new transaction type. Making the complexity opt-in sounds like a reasonable compromise. Btw, when are we starting officially working on IDB v2? :) ASAP! We've got some things implemented behind experimental flags in Chrome (binary keys, continuing-on-primary-key, etc) and want to push forward with more details on events, storage types (persistent vs. temporary) etc. Perhaps a topic for the F2F next month (offline or during the meeting?) would be current best practices for 'v2' specs? / Jonas
Re: On starting WebWorkers with blob: URLs...
On 2/19/14 7:09 PM, ext Jonas Sicking wrote: On Wed, Feb 19, 2014 at 3:51 PM, Travis Leithead travis.leith...@microsoft.com wrote: Seems like our specs are getting a little behind implementations. In IE11 we are finding that several new sites, notably those using WebGL content, have a dependency on starting web workers with a Blob URL. As I understand it: The W3C Web Workers spec (CR stage) forbids use of the data and [implicitly] blob protocols The WHATWG HTML spec (Living stage) allows data protocol, but not blob. Implementations of Firefox and Chrome support blob protocols 1. Seems like a spec should say this somewhere... Agreed! It's a bit tricky since the concept of origins and thus same origin for data: and blob: is a bit unclear still. I.e. browsers don't behave consistently. Definitely not between each other, and sometimes not internally within a browser IIRC. 2. In the W3C where would we spec this? (Workers V2?) I care less strongly about this. There's also the synchronous message passing API which I'd still like to see added to the workers spec. In addition to the changes mentioned above, during our TPAC 2013 meeting, we also talked briefly about a version of Workers that does not include Shared Workers [Mins]. I'm not opposed to working on a new version of Workers but I think it would be helpful to get the group's consensus re the plans and expectations for the Dec 2012 [CR]. The interop data James gathered in [James] is certainly more promising than the interop data in [Wiki] but James data does not include IE. As such, it's not clear to me what level of interop we have now for the 4 main browsers, nor if we have sufficient commitments from implementers to eventually exit CR (and if so, our best guestimate on when we can expect to meet the CR exit criteria). -AB [Mins] http://www.w3.org/2013/11/12-webapps-minutes.html#item08 [CR] http://www.w3.org/TR/2012/CR-workers-20120501/ [Wiki] https://www.w3.org/wiki/Webapps/Interop/WebWorkers [James] http://hoppipolla.co.uk/410/workers.html
Re: On starting WebWorkers with blob: URLs...
For what its worth, since then mozilla has implemented shared workers. I think they are in Aurora currently and reaching beta next week. So I believe we fulfill the two-implementations requirement. / Jonas On Mar 10, 2014 12:08 PM, Arthur Barstow art.bars...@nokia.com wrote: On 2/19/14 7:09 PM, ext Jonas Sicking wrote: On Wed, Feb 19, 2014 at 3:51 PM, Travis Leithead travis.leith...@microsoft.com wrote: Seems like our specs are getting a little behind implementations. In IE11 we are finding that several new sites, notably those using WebGL content, have a dependency on starting web workers with a Blob URL. As I understand it: The W3C Web Workers spec (CR stage) forbids use of the data and [implicitly] blob protocols The WHATWG HTML spec (Living stage) allows data protocol, but not blob. Implementations of Firefox and Chrome support blob protocols 1. Seems like a spec should say this somewhere... Agreed! It's a bit tricky since the concept of origins and thus same origin for data: and blob: is a bit unclear still. I.e. browsers don't behave consistently. Definitely not between each other, and sometimes not internally within a browser IIRC. 2. In the W3C where would we spec this? (Workers V2?) I care less strongly about this. There's also the synchronous message passing API which I'd still like to see added to the workers spec. In addition to the changes mentioned above, during our TPAC 2013 meeting, we also talked briefly about a version of Workers that does not include Shared Workers [Mins]. I'm not opposed to working on a new version of Workers but I think it would be helpful to get the group's consensus re the plans and expectations for the Dec 2012 [CR]. The interop data James gathered in [James] is certainly more promising than the interop data in [Wiki] but James data does not include IE. As such, it's not clear to me what level of interop we have now for the 4 main browsers, nor if we have sufficient commitments from implementers to eventually exit CR (and if so, our best guestimate on when we can expect to meet the CR exit criteria). -AB [Mins] http://www.w3.org/2013/11/12-webapps-minutes.html#item08 [CR] http://www.w3.org/TR/2012/CR-workers-20120501/ [Wiki] https://www.w3.org/wiki/Webapps/Interop/WebWorkers [James] http://hoppipolla.co.uk/410/workers.html
Re: [IndexedDB] Transaction ordering for readonly transactions
On Mar 10, 2014 10:35 AM, Joshua Bell jsb...@google.com wrote: This means that a readonly transaction that's started after a readwrite transaction may or may not see the data that was written by the readwrite transaction. This does seem like a nice optimization. Especially for implementations that use MVCC since it means that it can run the readonly and the readwrite transaction in parallel. Another benefit is that a connection that's issuing a series of readonly transactions won't suddenly pause just because a different connection in another page is starting a readwrite transaction. Good point. However I think the result is a bit confusing. I'm not so much worried that the fact that people will get callbacks in a different order matters. Even though in theory those callbacks could have sideeffects that will now happen in a different order. The more concerning thing is that the page will see different data in the database. One example of confusion is in this github thread: https://github.com/js-platform/filer/issues/128#issuecomment-36633317 This is a library which implements a filesystem API on top of IDB. Due to this optimization, writing a file and then checking if it exists may or may not succeed depending on if the transactions got reordered or not. And we (Chrome) have also had developer feedback that allowing readonly transactions to slip ahead' of busy/blocked readwrite transactions is surprising. That said, developers (1) have been quick to understand that implicit transaction ordering should be made explicit by not creating dependent transactions until the previous one has actually completed - and probably fixing some application logic bugs at the same time, and (2) have taken advantage of readonly transactions not blocking on readwrite transactions, achieving much higher throughput without implementing their own data caching layer. So I'm definitely of two minds here. Removing this optimization will help developers in simple cases, but would hinder larger scale web apps. Other opinions? I agree that supporting the high-peeformance use case is important. But it seems surprising that you can depend on transaction scedulibg for readwrite transactions but not for readonly. I.e. it seems strange that you can work around this optimization by switching your readonly transactions to readwrite (as was done in this case). I'd like to strengthen the default ordering requirements and say that two transactions must run in the order they were created if they have overlapping scopes and either of them is a readwrite transaction. But I'd be totally open to adding some syntax to opt in to more flexible transaction ordering. Possibly by introducing a new transaction type. Making the complexity opt-in sounds like a reasonable compromise. Cool, something like reordarable might work. reorderable-readonly is more descriptive but is terribly long. Another issue is feature detection. Maybe we should introduce functions like readonlyTransaction() readwriteTransaction() reorderableTransaction() (That would have also gotten us out of the extended argument we had about what the default transaction type should be) Btw, when are we starting officially working on IDB v2? :) ASAP! We've got some things implemented behind experimental flags in Chrome (binary keys, continuing-on-primary-key, etc) and want to push forward with more details on events, storage types (persistent vs. temporary) etc. Perhaps a topic for the F2F next month (offline or during the meeting?) would be current best practices for 'v2' specs? Sounds good! / Jonas
[Bug 24998] New: What is the origin of a blob: URL?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998 Bug ID: 24998 Summary: What is the origin of a blob: URL? Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: i...@hixie.ch QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org The spec says: This scheme should have an origin policy and a lifetime stipulation, to allow safe access to binary data from web applications. ...but where is this actually defined? -- You are receiving this mail because: You are on the CC list for the bug.
[push] Consider renaming push notification to push message in the Push API spec
The term push notification in https://dvcs.w3.org/hg/push/raw-file/tip/index.html#dfn-push-notification seems to confuse people into thinking that the user will be notified/bothered when such a message arrives. This is reinforced by the fact that iOS uses push notification for exactly that: a way to notify the user based on a message from a server. See https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/WhatAreRemoteNotif.html. Since the spec already uses the name PushMessage for the thing delivered by a push notification (https://dvcs.w3.org/hg/push/raw-file/tip/index.html#pushmessage-interface), it seems like push message would be a good replacement for the current ambiguous name. Thanks, Jeffrey Yasskin P.S. I'm not subscribed to public-webapps@, so please cc me if you want me to reply.
Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data
On Wed, Feb 12, 2014 at 1:25 AM, Hallvord R. M. Steen hst...@mozilla.comwrote:
Hi Hallvord!
Hi Ben! Thanks for responding to my request for feedback - especially
since the IE team has done some interesting work in this area and is
arguably ahead of the rest! :-)
The IE11 API you mentioned is msConvertURL [1] (also on the IE blog
[2]), and it was designed as a
simple way for sites to choose DataURI or Blob for otherwise
inaccessible images.
X
As you mention, it is not possible to tell which file/image corresponds
to which img because it’s
really designed as a simple approach for cases where a site wants to
always use blob or dataURI for
images that they couldn’t otherwise access.
That's more or less what I thought, based on the blog post, so thanks for
describing it in detail.
We are considering doing the CID approach as well in the future. It is
nice to have the additional
control of seeing which img src you are changing, and it will likely
work better for copy, not just
paste like convertURL.
Actually, I haven't truly considered the copy case here yet. I've sort of
assumed that given that you can put multiple bits of data on a clipboard,
the various clipboard implementations should already have a way one piece
of data can reference one specific other piece of data - I haven't really
found the technical details here.
I don't actually know of any native clipboard formats that allow data
associated with one format to reference other data in the same operation,
so browsers would have to roll their own implementation/figure out how to
get it to work well with native apps.
Of course it would be nice to support a script that wants to generate
random HTML with embedded files to place on the clipboard (although I think
most of those use cases can already be met by using URLs and assuming that
any software reading HTML from the clipboard can understand URLs..).
However, one can imagine a use case for example with a CANVAS app where the
script wants to copy the state of the CANVAS as an image inside HTML it
places on the clipboard - having the script create src=cid:n type markup,
append files, and make the UA translate that to the platform's native
clipboard implementation's way of referencing one part on the clipboard
from another part..
We believe that convertURL does not block using the CIDs you have in the
current spec.
I suppose not, but perhaps the more relevant question is: should we
standardise convertURL? Would it still have a use case if we take the cid:
route? (And I guess a related question is: given that we've done data: URLs
for a while, how much content will we break if, say, Firefox moves from
data: to cid:? Do we need to make cid: opt-in somehow, like you're doing
with convertURL?)
I'm trying to make sure I correctly understand how the IE11 version of this
works. From the sample (
http://msdn.microsoft.com/en-us/library/ie/dn254935(v=vs.85).aspx), it
looks like if a user pastes in some HTML that references local images, IE11
automatically captures the referenced files into the clipboard. Then the
page uses msConvertUrl() rewrites references to the src attributes in the
text/html DataTransferItem to reference the blob URLs, right?
Given that the drag data store is in read only mode at this point, it
seems weird to allow mutations at this point.
In addition, from a security perspective, what stops a malicious website
from embedding something like img src=file:///etc/passwd
style=display:none/img in the markup?
To better understand your approach and allow us to help move it forward,
can you give us sample
javascript that a site would use to set the DataTransferItems for HTML
and the related images during copy?
As I said, I have not really considered this use case - so the spec
doesn't actually cover this. If we want to make this work, I suppose the JS
would look somewhat like this?
document.addEventListener('copy', function(e){
// So, you want to copy the current status of your game? No
problem.
// Let's say this game generates a number of PNG graphics from
CANVAS tags
// and keeps them in memory in ArrayBuffers or something
var html = 'divbplayer/b\'s medals: img src=cid:1img
src=cid:2/div';
e.clipboardData.items.add(html, 'text/html');
e.clipboardData.items.add(new File(medals[0], 'medal.png',
{type:'image/png'}));
e.clipboardData.items.add(new File(medals[1], 'medal.png',
{type:'image/png'}));
e.preventDefault();
}, false);
Second, can you provide the javascript for how a site would put them
into the pasted markup during paste?
The way I thought this would work, would be that the site starts XHR
uploads from the paste processing, and shows some intermediate 'loading'
animation or something before it gets the final URLs back from the server.
A bit like this (although some things could be more elegant, like the
insertion of
