ServiceWorker: Update IDLs to use ScalarValueString

ServiceWorker: Update IDLs to use ScalarValueString

Based on the IDLs in the SW spec and now Fetch spec, use
ScalarValueString as appropriate.

Also, add cases to the overload resolution implementation for ByteString
(and ScalarValueString, though the spec hasn't caught up yet).

R=nbarth@chromium.org,haraken@chromium.org,horo@chromium.org
BUG=379009
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176531

[jsbell, 2014-06-18 22:14:30]

horo@, nbarth@, haraken@ - please take a look?

Should I add tests for some or all of the properties (e.g. register "\uD800",
verify that "\uFFFD" got registered instead), or should we trust in the bindings
code?

[haraken, 2014-06-18 23:29:27]

On 2014/06/18 22:14:30, jsbell wrote:
> horo@, nbarth@, haraken@ - please take a look?
> 
> Should I add tests for some or all of the properties (e.g. register "\uD800",
> verify that "\uFFFD" got registered instead), or should we trust in the
bindings
> code?

ScalarValueString is brand-new, so adding tests sounds nice.

Would you also add a link to the spec to the ServiceWorker IDL files? Nils did
that for a lot of existing IDL files and the links are helpful to understand how
the real IDL files match the spec.

LGTM.

[jsbell, 2014-06-19 00:31:27]

On 2014/06/18 23:29:27, haraken wrote:
> On 2014/06/18 22:14:30, jsbell wrote:
> > horo@, nbarth@, haraken@ - please take a look?
> > 
> > Should I add tests for some or all of the properties (e.g. register
"\uD800",
> > verify that "\uFFFD" got registered instead), or should we trust in the
> bindings
> > code?
> 
> ScalarValueString is brand-new, so adding tests sounds nice.

Added the easy one (a writable attribute); I forgot that registration scope is
initialized through a Dictionary so that can't be tested yet. The fetch() API is
the other one that's testable - horo@, is it stable enough to test at this
point?

> Would you also add a link to the spec to the ServiceWorker IDL files? Nils did
> that for a lot of existing IDL files and the links are helpful to understand
how
> the real IDL files match the spec.

Done. The ServiceWorker and Fetch specs are churning at lot; in the last day or
two all of the Request/Response/HeaderMap^H^H^H interfaces have migrated.

[haraken, 2014-06-19 00:50:57]

On 2014/06/19 00:31:27, jsbell wrote:
> On 2014/06/18 23:29:27, haraken wrote:
> > On 2014/06/18 22:14:30, jsbell wrote:
> > > horo@, nbarth@, haraken@ - please take a look?
> > > 
> > > Should I add tests for some or all of the properties (e.g. register
> "\uD800",
> > > verify that "\uFFFD" got registered instead), or should we trust in the
> > bindings
> > > code?
> > 
> > ScalarValueString is brand-new, so adding tests sounds nice.
> 
> Added the easy one (a writable attribute); I forgot that registration scope is
> initialized through a Dictionary so that can't be tested yet. The fetch() API
is
> the other one that's testable - horo@, is it stable enough to test at this
> point?
> 
> > Would you also add a link to the spec to the ServiceWorker IDL files? Nils
did
> > that for a lot of existing IDL files and the links are helpful to understand
> how
> > the real IDL files match the spec.
> 
> Done. The ServiceWorker and Fetch specs are churning at lot; in the last day
or
> two all of the Request/Response/HeaderMap^H^H^H interfaces have migrated.

Thanks, still LGTM. horo-san might want to take a look in terms of
ServiceWorker.

[horo, 2014-06-19 07:39:08]

lgtm

[jsbell, 2014-06-19 16:03:59]

The CQ bit was checked by jsbell@chromium.org

[commit-bot: I haz the power, 2014-06-19 16:04:34]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jsbell@chromium.org/340943002/20001

[commit-bot: I haz the power, 2014-06-19 17:48:14]

Change committed as 176531

[Nils Barth (inactive), 2014-06-20 01:06:30]

On 2014/06/18 23:29:27, haraken wrote:
> On 2014/06/18 22:14:30, jsbell wrote:
> > Should I add tests for some or all of the properties (e.g. register
"\uD800",
> > verify that "\uFFFD" got registered instead), or should we trust in the
> bindings
> > code?
> 
> ScalarValueString is brand-new, so adding tests sounds nice.

Agreed: in principle, general type behavior should be sufficiently covered by
e.g.
fast/js/webidl-type-mapping.html
...but as this is new and we don't have strict unit test separation,
it doesn't hurt.