For calling %Error%'s constructor, I vaguely guess that we can simply implement DOMException's constructor to call %Error%'s constructor (and do more work).

For generating |name| and |code| properties by the bindings generator, I vaguely think that it's not necessary (it's not a bindings generator's task).  |name| and |code| are not IDL attributes (nor operations nor constants), they're simple data properties without C++ callback functions.  So, as spec'ed, it's a task for DOMException's constructor to define own data properties named |name| and |code|.  Unless we want to generate a whole implementation of DOMException's constructor, it wouldn't be a task of the bindings generator.

In both cases, doesn't that mean DOMException's constructor on the impl side would need to be aware and have a pointer to the corresponding V8 object? I thought that was not desired/possible.

In the constructor call, v8::FunctionCallbackInfo<T>::NewTarget() returns the new object being constructed, and I think that it's just fine to use it.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/V8HTMLConstructor.cpp?sq=package:chromium&l=35
for example.

The V8HTMLConstructor bits are essentially a custom constructor, special-cased in the bindings templates and scripts. That could work, but I don't see how that differs much from adding an epilogue/prologue to the existing constructor, in that in all cases we're adding some custom bindings code (and doing something like V8HTMLConstructor would maybe require another extended attribute?)

One other thing: even if we go down this road and remove all those properties from the IDL file, what do we do with |message|? Neither spec mentions any special behavior, but we keep sanitized and unsanitized versions and have MessageForConsole() and ToStringForConsole(). If the existing distinction were to be kept, these methods would need to access the underlying V8 object to retrieve |message|.

re #4: Right.  In general, we don't like [Custom] and we'd like to reduce the number of [Custom], but IMHO there are several right use cases, too (take this as my personal opinion).  I think that we can replace [HTMLConstructor] with [CustomConstructor] and we can use [CustomConstructor] for DOMException, these use cases should be fine.  I personally prefer a few good use cases of [Custom/CustomConstructor] to adding more and more Blink-specific extended attributes.  Adding a Blink-specific extended attribute could be as bad as (or worse than) adding a use case of [Custom/CustomConstructor].

Having said that, I'm open to add a Blink-specific extended attribute if it's necessary or it's better in this case.

re #5:
> what do we do with |message|? Neither spec mentions any special behavior

https://heycam.github.io/webidl/#es-DOMException-call
It seems that we need to call DOMException.__proto__(message) where DOMException.__proto__ is %Error%'s constructor by default, but can be changed by author script.

https://tc39.github.io/ecma262/#sec-error-constructor
It seems that %Error%'s constructor defines an own data property named |message|.  The property is writable and configurable.


> If the existing distinction were to be kept, these methods would need to access the underlying V8 object to retrieve |message|.

That's a good question.  In addition to it, I have another question; do we want to show |message| property's value, which can be overwritten by author script, on console?  Or do we want to show our own internal (readonly) message?

Oops, I misunderstood that [HTMLConstructor] is Blink-specific, actually it is defined in HTML spec.  Then, [HTMLConstructor] is just fine.  My key point is that we're not so happy to introduce more Blink-specific extended attributes, and sometimes [Custom] is better than it (not always, though).

Understood. I can work towards using a custom constructor for DOMException in this case, but we need to decide what to do with |message| and its friends first.

Oh dear. This is unfortunately my mess, in spec-land. See https://github.com/heycam/webidl/issues/55.

The summary is that I tried to make DOMException a "proper" error subclass in the spec. However, that mismatched most (all?) browsers, so I've had a TODO since 2015 to revert it. I still think the spec is theoretically better with it being a proper error subclass, but I don't think it's worth the work for everyone.

Let me re-start the discussion on https://github.com/heycam/webidl/issues/55 so we can figure out the right thing to do.

I've posted a spec and tests PR for straightening all this out, which I hope will be merged soon:

- https://github.com/heycam/webidl/pull/378
- https://github.com/w3c/web-platform-tests/pull/6361

The latter link contains a list of which of the new tests Chrome fails.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0680af0b0a7b0a4eec1f792017085bba13493e88

commit 0680af0b0a7b0a4eec1f792017085bba13493e88
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Sun Jul 02 18:25:50 2017

bindings: Remove support for exception interfaces.

They were removed from the WebIDL spec in 2014 ("Removed IDL exceptions,
baked in DOMException, and added Error and DOMException as types"):
https://github.com/heycam/webidl/commit/50e172ec079db073c3724c9beac1b576fb5dbc47

Support for exception interfaces was implemented by treating them like
WebIDL interfaces and setting |is_exception| in IdlException (which
inherited from IdlInterface). Since DOMException was the only exception
interface we had in the tree, we can just turn it into a proper interface,
check for its name when we need to set |is_exception| and remove all the
lexer/parser/bindings scaffolding we had.

V8DOMException.{cpp,h} generated after the new DOMException.idl have been
verified to be identical to their previous version.

There is work upstream to make DOMException a proper interface (see
https://github.com/heycam/webidl/pull/378). This change can go in regardless
of the upstream pull request upstream takes, as exception interfaces have
been dead and gone for years.

Bug: 617899, 737497
Change-Id: Iea16c7da733180cd61b14471d0758d5dd68158dc
Reviewed-on: https://chromium-review.googlesource.com/558088
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#483921}
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/third_party/WebKit/Source/bindings/scripts/idl_definitions.py
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/third_party/WebKit/Source/bindings/scripts/idl_reader.py
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/third_party/WebKit/Source/bindings/scripts/utilities.py
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/third_party/WebKit/Source/bindings/scripts/v8_interface.py
[delete] https://crrev.com/829f2e0b37d0175ac65aee0cbc9a603fcc994db7/third_party/WebKit/Source/bindings/tests/idls/core/TestException.idl
[delete] https://crrev.com/829f2e0b37d0175ac65aee0cbc9a603fcc994db7/third_party/WebKit/Source/bindings/tests/results/core/V8TestException.cpp
[delete] https://crrev.com/829f2e0b37d0175ac65aee0cbc9a603fcc994db7/third_party/WebKit/Source/bindings/tests/results/core/V8TestException.h
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/third_party/WebKit/Source/core/dom/DOMException.idl
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/tools/idl_parser/idl_lexer.py
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/tools/idl_parser/idl_parser.py
[modify] https://crrev.com/0680af0b0a7b0a4eec1f792017085bba13493e88/tools/idl_parser/test_lexer/keywords.in
[delete] https://crrev.com/829f2e0b37d0175ac65aee0cbc9a603fcc994db7/tools/idl_parser/test_parser/exception_web.idl

> I've posted a spec and tests PR for straightening all this out, which I hope will be merged soon:

Thanks a lot for picking this up, Domenic. That made my life a lot easier :-)

I've updated the bug description now that we don't deviate that much from the spec and the bug's a lot easier to tackle.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/b9b8cc9bad0128bf07638c138d709a50433884f1

commit b9b8cc9bad0128bf07638c138d709a50433884f1
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Fri Jul 07 06:42:59 2017

Expose %ErrorPrototype% as an intrinsic in the public API.

Blink needs %ErrorPrototype% in order to properly set up the inheritance
chain from DOMException, as specified in WebIDL:
https://heycam.github.io/webidl/#es-DOMException-specialness

This patch is similar to commit 5ec1cddcd ("Expose %IteratorPrototype% as an
intrinsic in the public API"), with the difference that there was no entry
for %ErrorPrototype% in any of the mappings in contexts.h.

Bug:  chromium:556950 , chromium:737497
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iadc5b2b844f29f6c9640b6a89769d233931366e9
Reviewed-on: https://chromium-review.googlesource.com/559058
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#46464}
[modify] https://crrev.com/b9b8cc9bad0128bf07638c138d709a50433884f1/include/v8.h
[modify] https://crrev.com/b9b8cc9bad0128bf07638c138d709a50433884f1/src/bootstrapper.cc
[modify] https://crrev.com/b9b8cc9bad0128bf07638c138d709a50433884f1/src/contexts.h
[modify] https://crrev.com/b9b8cc9bad0128bf07638c138d709a50433884f1/test/cctest/test-api.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be24cfe8bb8e232d1c48631f1175009e66204b40

commit be24cfe8bb8e232d1c48631f1175009e66204b40
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Wed Jul 12 15:29:41 2017

Remove toString() override from DOMException.

Adapt to https://github.com/heycam/webidl/pull/378 ("Re-align DOMException
objects with what is implemented").

We were reimplementing toString() in DOMException because of WebKit
r29058 ("Acid3 expects ExeceptionCode constants to be defined on
DOMException objects") from almost 10 years ago. A lot has happened since,
and we can (and should) just use the toString() implementation from
ECMAScript's %ErrorProtoype% (which is explicitly mandated to be in
DOMException's inheritance chain by the WebIDL spec).

Contrary to what's originally described in  bug 556950 , we do throw an
exception when DOMException.prototype.toString() is called directly: the
WebIDL spec now expects it to, and
https://github.com/w3c/web-platform-tests/pull/6361 tests this behavior.

Additionally, we've changed the way DOMException inherits from
%ErrorPrototype%: instead of doing it in V8PerContextData, we now do it in
V8DOMException::installV8DOMExceptionTemplate(), as the former had problems
with (i)frames detached from the DOM and toString() would just call
Object.prototype.toString() instead.

The only user-visible part of the change is that "toString" is no longer
part of DOMException.prototype's own properties; the error message format is
exactly the same in most cases (the exact steps are described in
https://tc39.github.io/ecma262/#sec-error.prototype.tostring).

Finally, part of http/tests/plugins/cross-frame-object-access.html's
output will change from:
    "Error: Uncaught [object DOMException]"
to
    "Error: Uncaught"
This is tricky because it involves PPAPI and its separate process, but
basically the plugin in an iframe is trying to access top.location.href,
Blink is throwing a SecurityError, but the error message is sent truncated
to PPAPI. The message is truncated because V8 is calling its
NoSideEffectsErrorToString() when creating the message, and this one does
not use the message/name accessors we install, leading to an empty message
(it looked slightly better before because we the presence of our own
toString() caused Object::NoSideEffectsToString() to choose a different
albeit still wrong code path). Blink's handling of this is fine, as the
code in V8Initializer takes care of extracting the name and error message
from the DOMException V8 object that threw the exception.

Bug:  556950 , 737497
Change-Id: I9d81edca1de903364bb1aca5950c313885c5964a
Reviewed-on: https://chromium-review.googlesource.com/558904
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#485960}
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/crypto/subtle/aes-cbc/decrypt-failures-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/crypto/subtle/ecdh/import-export-raw-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/crypto/subtle/rsa-oaep/plaintext-length-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/http/tests/plugins/cross-frame-object-access-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/http/tests/serviceworker/webexposed/global-interface-listing-service-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/platform/mac/virtual/stable/http/tests/serviceworker/webexposed/global-interface-listing-service-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/platform/mac/virtual/stable/webexposed/global-interface-listing-dedicated-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/platform/mac/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/platform/mac/virtual/stable/webexposed/global-interface-listing-shared-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/platform/win/virtual/stable/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/service-worker-navigation-preload-disabled/http/tests/serviceworker/webexposed/global-interface-listing-service-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/service-worker-navigation-preload-disabled/webexposed/global-interface-listing-dedicated-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/service-worker-navigation-preload-disabled/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/service-worker-navigation-preload-disabled/webexposed/global-interface-listing-shared-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/service-worker-navigation-preload/http/tests/serviceworker/webexposed/global-interface-listing-service-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/stable/http/tests/serviceworker/webexposed/global-interface-listing-service-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/stable/webexposed/global-interface-listing-dedicated-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/virtual/stable/webexposed/global-interface-listing-shared-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-dedicated-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-shared-worker-expected.txt
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/Source/bindings/core/v8/serialization/V8ScriptValueSerializerTest.cpp
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/Source/bindings/templates/interface_base.cpp.tmpl
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/Source/core/dom/DOMException.cpp
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/Source/core/dom/DOMException.h
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/Source/core/dom/DOMException.idl
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/Source/platform/bindings/V8PerContextData.cpp
[modify] https://crrev.com/be24cfe8bb8e232d1c48631f1175009e66204b40/third_party/WebKit/Source/platform/bindings/V8PerContextData.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/50cee626beeff9232c93a6e4c7c6d3944b9582e6

commit 50cee626beeff9232c93a6e4c7c6d3944b9582e6
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Thu Jul 13 10:35:19 2017

bindings: Remove WrapperTypeInfo::kWrapperTypeExceptionPrototype.

https://chromium-review.googlesource.com/c/558904 ("Remove toString()
override from DOMException") changed the way DOMException's inheritance
chain was set up, and its function object now inherits from %ErrorPrototype%
in V8DOMException::installV8DOMExceptionTemplate().

Since DOMException was the only user of kWrapperTypeExceptionPrototype, we
can remove it from WrapperTypeInfo::WrapperTypePrototype and clean up the
code a little.

Bug: 737497
Change-Id: I532431eb57839a7c7e0df35e250ada2426be5b75
Reviewed-on: https://chromium-review.googlesource.com/569700
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hitoshi Yoshida <peria@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#486334}
[modify] https://crrev.com/50cee626beeff9232c93a6e4c7c6d3944b9582e6/third_party/WebKit/Source/bindings/scripts/v8_interface.py
[modify] https://crrev.com/50cee626beeff9232c93a6e4c7c6d3944b9582e6/third_party/WebKit/Source/bindings/templates/interface_base.cpp.tmpl
[modify] https://crrev.com/50cee626beeff9232c93a6e4c7c6d3944b9582e6/third_party/WebKit/Source/platform/bindings/WrapperTypeInfo.h

At the moment, we're only failing a single test from w-p-t's WebIDL/ecmascript-binding/es-exceptions: DOMException-custom-bindings.any.html's check for the "stack" property in DOMException.

The spec says "if an implementation gives native Error objects special powers or nonstandard properties (such as a stack property), it should also expose those on DOMException instances". Right now we do that via V8ThrowDOMException, which means DOMExceptions thrown by Blink itself do expose a stack property, while DOMException objects created in user scripts do not.

I sent an email to v8-dev a few weeks ago to discuss moving Error.stack to Error.prototype.stack, which would solve our problems automagically, but it wasn't met with a lot of enthusiasm: https://groups.google.com/d/msg/v8-dev/nQVOwXFqVnE/DWV_CNv0BAAJ

At a glance, it seems that we have at least a few options here.
1) The current status is just enough.  Wait for a while until something happens (on V8 or ECMAScript?).
2) Update the DOMException's wrapper creation (regardless of whether it's called from author script or internally) so that the constructor always installs "stack" attribute.
3) Drive the discussion with V8 team.

I was leaning towards 2) at first, but didn't find a nice way to move
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/V8ThrowDOMException.cpp?q=v8throwdom&sq=package:chromium&l=64 to DOMException itself: in terms of which Isolate and Context to use, for example, as well as how to change V8PrivateProperty::DOMExceptionError from DOMException itself.

Can we create a [CustomConstructor] for DOMException?  Then, we should be able to do anything we want.

The custom constructor takes |info| as the argument, then
- info.GetIsolate()
- info.GetIsolate()->GetCurrentContext()
- info.NewTarget()
are the isolate and context that we should use, and the new DOMException object being created.  You can add a private property to info.NewTarget().

Supposing that exception_obj = info.NewTarget().As<v8::Object>();
you should be able to do almost the same thing as the current implementation.

Also see:
https://cs.chromium.org/chromium/src/out/Debug/gen/blink/bindings/core/v8/V8DOMException.cpp?type=cs&q=V8DOMException+constructor+case:yes&sq=package:chromium&l=93

Having said that, I've not given it a try and not quite sure if this goes well or not.  Just an idea.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9

commit 550d62d7eb5fc6f269b3568df6ba48d3221fcdc9
Author: Joshua Bell <jsbell@chromium.org>
Date: Wed Jul 26 16:13:36 2017

Add real baselines for new .any.js and .worker.js tests (batch 1 of N)

In a few cases there were obvious bugs in WPT which were fixed.
In most cases baselines were added (expected.txt files with FAIL).

This batch covers: (with commentary where interesting)
* FileAPI: fixes for WPT; update IDL fragments with Exposed
* IndexedDB: fixes for WPT; make DOMStringList untested here
* WebIDL: DOMException bindings (crbug.com/737497)
* background-fetch
* dom: AbortController (NYI in blink?)
* dom: EventTarget constructor (NYI in blink,  crbug.com/740576 )
* fetch/api
* html: dom/interfaces.worker.js is broken upstream [1]
* storage: renamed test with .https infix
* url
* workers

[1] https://github.com/w3c/web-platform-tests/issues/6621

Bug:  748723 , 740576 ,737497
Change-Id: I081412709886e55f2eadd7f21156712060319412
Reviewed-on: https://chromium-review.googlesource.com/585582
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Jeff Carpenter <jeffcarp@chromium.org>
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489659}
[modify] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/FileAPI/idlharness.html
[modify] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/FileAPI/idlharness.worker.js
[modify] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/interfaces.html
[modify] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/interfaces.idl
[modify] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/interfaces.worker.js
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/WebIDL/ecmascript-binding/es-exceptions/DOMException-custom-bindings.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/WebIDL/ecmascript-binding/es-exceptions/DOMException-custom-bindings.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/background-fetch/interfaces.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/dom/abort/event.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/dom/abort/event.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/dom/events/EventTarget-constructible.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/dom/events/EventTarget-constructible.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/basic/request-upload.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/basic/request-upload.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/basic/scheme-about.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/basic/scheme-about.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/cors/cors-preflight-redirect.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/cors/cors-preflight-redirect.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/cors/cors-preflight-referrer.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/cors/cors-preflight-referrer.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/cors/cors-preflight-star.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/fetch/api/cors/cors-preflight-star.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/html/dom/interfaces.worker-expected.txt
[rename] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/storage/interfaces.https.worker.js
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/url/historical.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/url/historical.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/url/interfaces.any-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/url/interfaces.any.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/url/toascii.window-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/workers/constructors/Worker/DedicatedWorkerGlobalScope-members.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/workers/constructors/Worker/expected-self-properties.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/workers/interfaces.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/workers/interfaces/WorkerUtils/importScripts/002.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/workers/semantics/interface-objects/001.worker-expected.txt
[add] https://crrev.com/550d62d7eb5fc6f269b3568df6ba48d3221fcdc9/third_party/WebKit/LayoutTests/external/wpt/workers/semantics/interface-objects/002.worker-expected.txt