[Bug 25914] No definition of parsing blob's scheme data

2014-06-19 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #28 from Anne ann...@annevk.nl ---
Don't check for parse error, see if the algorithm returns failure.

Also, it may not return a host or port. You should probably check if it's a
relative scheme.

I think you probably just want to parse it and then say something like return
/parsedURL/'s origin.

But maybe I should just bite the bullet and define origin for all URL schemes
we care about.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 25987] Blob URL parsing / fetching model

2014-06-19 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987
Bug 25987 depends on bug 25914, which changed state.

Bug 25914 Summary: No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: Indexed DB Transactions vs. Microtasks

2014-06-19 Thread Anne van Kesteren
On Thu, Jun 19, 2014 at 7:48 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
 Hmm, it seems pretty related to me. In particular if we say that the IDB 
 microtask bucket always runs after all other microtask buckets, doesn't that 
 achieve the goals?

He said after each microtask (singular).


-- 
http://annevankesteren.nl/



Re: Indexed DB Transactions vs. Microtasks

2014-06-19 Thread Adam Klein
On Fri, Jun 6, 2014 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell jsb...@google.com wrote:
  case 1:
 
var tx;
Promise.resolve().then(function() {
  tx = db.transaction(storeName);
  // tx should be active here...
}).then(function() {
  // is tx active here?
});
 
  For case 1, ISTM that yes matches the IDB spec, since control has not
  returned to the event loop while the microtasks are running.
 Implementations
  appear to agree.

 Yes. I believe that this is what the spec currently calls for.

 However I think it would actually be good to change the spec to say
 that the transaction is closed at the end of the current microtask.

 When we originally designed microtasks for Mutation Observers, one of
 the goals was to ensure that there were not accidental
 interdependencies between different event handlers to the same event.
 By flushing end-of-microtask work after each event handler you ensure
 that each event handler gets a clean slate.

 I realize that this is a backwards-incompatible change. However it
 seems pretty unlikely to break any existing content. So it'd be nice
 to give it a try.


While I agree that the original microtask intent would suggest we change
this, and I concur that it seems unlikely to break content, I worry about
the spec and implementation complexity that would be incurred by having to
support the notion of at the end of the current microtask. It suggests
one of:

1. A new task queue, which runs after microtasks (nanotasks?)
2. The ability to put tasks at the start of the microtask queue rather than
at the end

(1) seems like a bad idea for a variety of reasons, not least of which that
it would soon lead us to need picotasks once an actor other than IDB saw a
need for it.

(2) strikes me as just plain hard to reason about. And again, if anyone
other than IDB tried to use that capability, it would become problematic.

Code running at end-of-microtask already has to deal with being in a
slightly different environment than normal event-handling code. I think
it might be worth avoiding additional complexity to make this quirk one of
those caveats.

- Adam


CORS, Preflight caching and Access-Control-Policy-

2014-06-19 Thread Garet Claborn
I was thinking about CORS and preflight caching lately, and came upon
these previous discussions:

http://lists.w3.org/Archives/Public/public-appformats/2008May/0039.html
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0228.html

Presumably there are a numerous others which I haven't read; so
apologies if my suggestion has been brought up previously. Still, I
thought to present a solution strategy in case there's anything of use
in it.

( 1. )
The simplest idea is to add mask and depth headers:

Access-Control-Policy-Path: /path/to/api
Access-Control-Policy-Mask-Path: /private
Access-Control-Policy-Mask-Path: /product/partner
Access-Control-Policy-Mask-Depth: 2

In this scheme, the intent would be that, assuming * for
Access-Control, and URL which is up to two levels more-deeply nested
than /path/to/api is publicly available and preflights may be cached
as a group.

So, this includes URLs such as
/path/to/api/products
/path/to/api/products/red  - but not
/path/to/api/products/red/small

Additionally this imposes that, regardless of depth, the
access-control does not apply to any url on or in
/path/to/api/private or
/path/to/api/product/partner

In this scheme, both Mask-Path and Mask-Depth are relative to the
Policy-Path. By applying a list of mask sub-paths and restricting
depth, security can be relaxed for only a small range of endpoints.


( 2. )
As a possible an extension to this, we could introduce sequential sets
where each Access-Control-* header refers to the Access-Control header
which appears most recently before it.

i.e.

Access-Control-Scheme: PUBLIC_API
Access-Control-Allow-Origin: *
Access-Control-Policy-Path: /path/to/api
Access-Control-Policy-Mask-Path: /private
Access-Control-Policy-Mask-Depth: 2

Access-Control-Scheme: PRIVATE_API
Access-Control-Allow-Origin: scheme://internal.host:port
Access-Control-Policy-Path: /path/to/api/private
Access-Control-Policy-Mask-Path: /private
Access-Control-Policy-Mask-Depth: 5


( 3 )

If elements of the prior two concepts were acceptable, it would be
possible for either an endpoint or a client-context (ex: a web service
or a page calling some ajax) to define a single broker for the given
service. This could be by either the calling 'page' or the service
defining a header:

Access-Control-Scheme: PUBLIC_API
Access-Control-Broker: scheme://internal.host:port/[optional]


The broker can in turn only assign access control to paths more deeply
nested than itself or sub-domains extending further left toward the
scheme (scheme://sub.internal.host:port).

In this case, the Access-Control-Scheme must match one provided by
the broker or else access will default to the current practice based
on return headers. If the service returns an Access-Control-Broker,
then a second preflight would be initiated. It is preferred that a
broker is known for clients implementing an API, or may be queried
somehow, allowing them to avoid access-based interaction with
services.

This should allow larger organizations to have fine-grained control
over multi-variant ranges and has the benefit of keeping preflight
contained to dedicated areas which may have the side-effect of
increasing security over current methods. At the same time, scripting
services becomes more convenient for UA which support this but are not
less capable of defining their own Access-Control per-endpoint.

One further note, any access-control broker should only be allowed to
specify a scheme for sub-domains of it's own host. Any path-based
broker should not be allowed to specify a scheme outside of it's
current host, including sub-domains. This stated with the idea that
the root-most URLs shall hold precedence but overrides are possible
only for deeper URL structures.

Thus service.domain.com/team1/api cannot define a broker to
service.domain.com/team2/api or
subsrv.service.domain.com/team1/api


Some aspects of this proposal could most likely be enhanced and/or
simplified. There's quite a bit I do not know about the current state
of discussion in this area. Simply, I hope that we'll eventually have
a cleaner interface towards securing CORS and automating access across
networks.

Cheers, -Garet Claborn
ga...@approach.im




[Bug 26142] New: execCommand() should work on textarea and input.

2014-06-19 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26142

Bug ID: 26142
   Summary: execCommand() should work on textarea and input.
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
  Assignee: a...@aryeh.name
  Reporter: andyearnshaw...@gmail.com
QA Contact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org

Currently, the editing spec defines that something is editable when the
following is true[1]:

 Something is editable if it is a node; it is not an editing host; 
 it does not have a contenteditable attribute set to the false state; 
 its parent is an editing host or editable; and either it is an HTML 
 element, or it is an svg or math element, or it is not an Element 
 and its parent is an HTML element.

I think this should be expanded to include HTML form fields that can accept
text input.  This is already the behaviour in Chrome and Internet Explorer for
some commands, though Firefox throws an error[2].

Although the majority of formatting commands might be useless, insertText, 
delete and forwardDelete could be useful for JavaScript based IMEs/virtual
keyboards, along with cut, copy, paste, undo, redo and selectAll from the
miscellaneous commands.  

There's also a use case for editors that switch between a designmode enabled
iframe for formatted editing and a text area for raw editing - these editors
would be able to reuse a lot of the same very short code (especially in the
case of insertText) without having to slice, concat and set the element
values.

[1]: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1027560

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: CORS, Preflight caching and Access-Control-Policy-

2014-06-19 Thread Anne van Kesteren
On Tue, Jun 17, 2014 at 11:27 PM, Garet Claborn ga...@approach.im wrote:
 Some aspects of this proposal could most likely be enhanced and/or
 simplified. There's quite a bit I do not know about the current state
 of discussion in this area. Simply, I hope that we'll eventually have
 a cleaner interface towards securing CORS and automating access across
 networks.

I might be missing something, but I don't see how these secure against
the IIS bug.

We could ignore that bug and put a warning sign in the specification,
as Ian suggested back then. Is there sufficient usage of CORS to add
the complexity? And, are server administrators okay with this being
possible?

The most attractive solution would be to do an OPTIONS * fetch of
sorts against a given host. Because basically the entire preflight
thing is a dance to figure out if the server knows about CORS.


-- 
http://annevankesteren.nl/



[Bug 26143] New: Create request early on

2014-06-19 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26143

Bug ID: 26143
   Summary: Create request early on
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: ann...@annevk.nl
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Refactor XMLHttpRequest to create a request early on and just fill in the
variables there rather than keep them around separately.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 26014] FormData.append with a string value appears not specified

2014-06-19 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26014

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are on the CC list for the bug.