lib: make DOMException attributes configurable and enumerable #22550

joyeecheung · 2018-08-27T09:17:36Z

The name, message and code attributes of the DOMException
interface should be enumerable and configurable. Aligning
the definition with the Web allows us to use it when
running the Web Platform Tests.

Refs: https://heycam.github.io/webidl/#idl-DOMException
Refs: web-platform-tests/wpt@125950d

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

nodejs-github-bot · 2018-08-27T09:17:38Z

@joyeecheung build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/695/pipeline

TimothyGu

Thanks for this – not sure how I overlooked it when creating the class. I have become a fan of the way TextEncoder sets the property descriptor bits though, as something like this:

class DOMException ... {
  get name() {
    // …
  }
  get message() {
    // …
  }
}
Object.defineProperties(DOMException.prototype, {
  name: { enumerable: true },
  message: { enumerable: true }
});

This has several advantages, the first being that we can continue to use the nice class syntax, and the second being that Object.getOwnPropertyDescriptor(DOMException.prototype, 'name').get.name would be 'get name' rather than 'get', which is what the IDL spec mandates (see step 3).

devsnek

couldn't we also use defineIDLClass

joyeecheung · 2018-08-27T20:17:46Z

I have become a fan of the way TextEncoder sets the property descriptor bits though, as something like this:

@TimothyGu Indeed that looks nicer! Thanks for the suggestion, I'll switch to that.

couldn't we also use defineIDLClass

@devsnek defineIDLClass doesn't seem to deal with attributes ATM..we may want to split that into a separate file dedicated to IDL bindings and add support for attributes later.

jdalton · 2018-08-28T05:46:31Z

I have mixed feels about Node throwing DOM exceptions.

Update:

I mean if we're doing it, then it should be correct, but I can see this being slippery.

jdalton

By the IDL shouldn't DOMException be exposed on the global and worker context?

TimothyGu · 2018-08-28T15:32:48Z

lib/internal/domexception.js

@@ -43,6 +43,12 @@ class DOMException extends Error {
  }
 }

+Object.defineProperties(DOMException.prototype, {
+  name: { enumerable: true, configurable: true },


Nit: the configurable: true isn't necessary, as the property is already configurable and Object.defineProperties won't override it.

I'd prefer to be explicit here since Object.defineProperties will read inherited properties of descriptors and Node internals aren't run in an isolated realm yet.

DOMException was created right above this with its prototype having them as own properties, so that is not an issue here.

TimothyGu · 2018-08-28T15:35:56Z

@jdalton, it was a conscious decision when the class was added to not expose it globally, precisely because of the "slippery slope" you mentioned. It is instead only used where it's necessary for compatibility with HTML's MessagePort. In any case, even if we were to do such a change it should be a separate PR, consistent with the tradition of making Web-derived classes globals in their own PRs.

jdalton · 2018-08-28T16:46:12Z

~~By the IDL does DOMException error have a .code property?~~

Ah, it does 👍

Update:

Other thought: I'm not sure if it's implied but at least in Chrome the DOMException.prototype has a Symbol.toStringTag value of "DOMException".

TimothyGu · 2018-08-28T19:02:35Z

Other thought: I'm not sure if it's implied but at least in Chrome the DOMException.prototype has a Symbol.toStringTag value of "DOMException".

Oh yeah, this probably needs

  [Symbol.toStringTag]: { configurable: true, value: 'DOMException' }

@jdalton Would you be open to approving this PR once that's fixed?

jdalton · 2018-08-28T21:42:43Z

Would you be open to approving this PR once that's fixed?

Yep, this is already out of the bottle. The main reason I held is because it had more than 2 approvals, meaning a merge could be imminent, and I wanted a bit more discussion.

joyeecheung · 2018-08-29T02:26:57Z

Yep, this is already out of the bottle. The main reason I held is because it had more than 2 approvals, meaning a merge could be imminent, and I wanted a bit more discussion.

I don't quite understand...do you want more discussion about the enumerability of these existing properties? If not, in general we open new issues or PRs to discuss, instead of trying to fix everything in one PR.

jdalton · 2018-08-29T21:31:06Z

Following up, I dug up spec bits I think are relevant for the Symbol.toStringTag value.

The Symbol.toStringTag addition spec'd for DOMException here:

and

and

While it doesn't state having Symbol.toStringTag on the prototype we could follow Chrome's lead (and it matches how it's handled in other builtins).

joyeecheung · 2018-08-30T04:01:49Z

@jdalton Can you open another PR for the Symbol.toStringTag changes? Maybe also with

By the IDL shouldn't DOMException be exposed on the global and worker context?

that you requested? I don't see why those have to be fixed in this particular PR and block this one?

jdalton · 2018-08-30T04:10:42Z

My requested change is in line with "align DOMException with the Web" and is just an additional line after the 3 properties you've defined.

joyeecheung · 2018-08-30T04:42:37Z

My requested change is in line with "align DOMException with the Web" and is just an additional line after the 3 properties you've defined.

Does it help if I change the commit title to "lib: make DOMException attributes configurable and enumerable"?

I don't mind fixing those myself, but personally even if I fix them in this PR I would not squash them into the first commit when I land the changes, so I'd prefer to have another PR open for that (In general I prefer to squash every commit in one PR whenever possible and keep commits that should be separated in different PR).

BridgeAR

LGTM (no matter if we add the toStringTag in this PR or not and no strong opinion about explicitly adding configurable: true)

The `name`, `message` and `code` attributes of the DOMException interface should be enumerable and configurable. Aligning the definition with the Web allows us to use it when running the Web Platform Tests. Refs: https://heycam.github.io/webidl/#idl-DOMException

joyeecheung · 2018-09-16T00:25:18Z

Rebased and renamed the PR to focus on the enumerability and configurability. I think other compliance issues can be dealt with in another PR - I'll open one next week if no one picks it up.

CI: https://ci.nodejs.org/job/node-test-pull-request/17211/

joyeecheung · 2018-09-16T00:26:32Z

@jdalton Do you insist that this PR fixing the enumerability and configurability cannot land until other attributes get fixed?

jdalton · 2018-09-16T03:23:24Z

@joyeecheung Yes please. It's a single additional attribute and I believe a reasonable change request.

Move to #22933

joyeecheung · 2018-09-18T14:22:00Z

CI: https://ci.nodejs.org/job/node-test-pull-request/17292/

joyeecheung · 2018-09-18T14:23:59Z

Per @jdalton 's request this is blocked by #22933 (though I still don't quite understand the reasoning behind this PR fixing the enumerability and configurability cannot land until other attributes get fixed)

joyeecheung · 2018-09-19T02:02:11Z

CI is green

PR-URL: #22933 Refs: #22550 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: John-David Dalton <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>

joyeecheung · 2018-09-20T16:07:39Z

Landed in 676bd5f, thanks!

The `name`, `message` and `code` attributes of the DOMException interface should be enumerable and configurable. Aligning the definition with the Web allows us to use it when running the Web Platform Tests. Refs: https://heycam.github.io/webidl/#idl-DOMException PR-URL: #22550 Refs: web-platform-tests/wpt@125950d Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: John-David Dalton <[email protected]> Reviewed-By: James M Snell <[email protected]>

PR-URL: #22933 Refs: #22550 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: John-David Dalton <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>

The `name`, `message` and `code` attributes of the DOMException interface should be enumerable and configurable. Aligning the definition with the Web allows us to use it when running the Web Platform Tests. Refs: https://heycam.github.io/webidl/#idl-DOMException PR-URL: #22550 Refs: web-platform-tests/wpt@125950d Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: John-David Dalton <[email protected]> Reviewed-By: James M Snell <[email protected]>

TimothyGu reviewed Aug 27, 2018

View reviewed changes

devsnek approved these changes Aug 27, 2018

View reviewed changes

addaleax approved these changes Aug 27, 2018

View reviewed changes

jdalton previously requested changes Aug 28, 2018

View reviewed changes

TimothyGu approved these changes Aug 28, 2018

View reviewed changes

BridgeAR approved these changes Sep 5, 2018

View reviewed changes

joyeecheung force-pushed the enum-dom branch from f1dd395 to c4d3df8 Compare September 16, 2018 00:18

joyeecheung changed the title ~~lib: align DOMException with the Web~~ lib: make DOMException attributes configurable and enumerable Sep 16, 2018

joyeecheung mentioned this pull request Sep 18, 2018

lib: set Symbol.toStringTag of DOMException #22933

Closed

2 tasks

joyeecheung added the blocked PRs that are blocked by other issues or PRs. label Sep 18, 2018

joyeecheung mentioned this pull request Sep 18, 2018

CI failures: 20180918 nodejs/reliability#16

Closed

jdalton approved these changes Sep 19, 2018

View reviewed changes

jasnell approved these changes Sep 19, 2018

View reviewed changes

joyeecheung closed this Sep 20, 2018

targos mentioned this pull request Oct 7, 2018

Release proposal: v10.12.0 #23313

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

lib: make DOMException attributes configurable and enumerable #22550

lib: make DOMException attributes configurable and enumerable #22550

joyeecheung commented Aug 27, 2018

nodejs-github-bot commented Aug 27, 2018

TimothyGu left a comment •

edited

Loading

devsnek left a comment

joyeecheung commented Aug 27, 2018

jdalton commented Aug 28, 2018 •

edited

Loading

jdalton left a comment •

edited

Loading

TimothyGu Aug 28, 2018

jdalton Aug 28, 2018

TimothyGu Aug 28, 2018

TimothyGu commented Aug 28, 2018

jdalton commented Aug 28, 2018 •

edited

Loading

TimothyGu commented Aug 28, 2018

jdalton commented Aug 28, 2018 •

edited

Loading

joyeecheung commented Aug 29, 2018

jdalton commented Aug 29, 2018

joyeecheung commented Aug 30, 2018

jdalton commented Aug 30, 2018

joyeecheung commented Aug 30, 2018 •

edited

Loading

BridgeAR left a comment

joyeecheung commented Sep 16, 2018

joyeecheung commented Sep 16, 2018

jdalton commented Sep 16, 2018

joyeecheung commented Sep 18, 2018

joyeecheung commented Sep 18, 2018 •

edited

Loading

joyeecheung commented Sep 19, 2018

joyeecheung commented Sep 20, 2018

lib: make DOMException attributes configurable and enumerable #22550

lib: make DOMException attributes configurable and enumerable #22550

Conversation

joyeecheung commented Aug 27, 2018

Checklist

nodejs-github-bot commented Aug 27, 2018

TimothyGu left a comment • edited Loading

Choose a reason for hiding this comment

devsnek left a comment

Choose a reason for hiding this comment

joyeecheung commented Aug 27, 2018

jdalton commented Aug 28, 2018 • edited Loading

jdalton left a comment • edited Loading

Choose a reason for hiding this comment

TimothyGu Aug 28, 2018

Choose a reason for hiding this comment

jdalton Aug 28, 2018

Choose a reason for hiding this comment

TimothyGu Aug 28, 2018

Choose a reason for hiding this comment

TimothyGu commented Aug 28, 2018

jdalton commented Aug 28, 2018 • edited Loading

TimothyGu commented Aug 28, 2018

jdalton commented Aug 28, 2018 • edited Loading

joyeecheung commented Aug 29, 2018

jdalton commented Aug 29, 2018

joyeecheung commented Aug 30, 2018

jdalton commented Aug 30, 2018

joyeecheung commented Aug 30, 2018 • edited Loading

BridgeAR left a comment

Choose a reason for hiding this comment

joyeecheung commented Sep 16, 2018

joyeecheung commented Sep 16, 2018

jdalton commented Sep 16, 2018

joyeecheung commented Sep 18, 2018

joyeecheung commented Sep 18, 2018 • edited Loading

joyeecheung commented Sep 19, 2018

joyeecheung commented Sep 20, 2018

TimothyGu left a comment •

edited

Loading

jdalton commented Aug 28, 2018 •

edited

Loading

jdalton left a comment •

edited

Loading

jdalton commented Aug 28, 2018 •

edited

Loading

jdalton commented Aug 28, 2018 •

edited

Loading

joyeecheung commented Aug 30, 2018 •

edited

Loading

joyeecheung commented Sep 18, 2018 •

edited

Loading