lib: brand-check Navigator getters to throw ERR_INVALID_THIS#63601
lib: brand-check Navigator getters to throw ERR_INVALID_THIS#636013zrv wants to merge 2 commits into
Conversation
Fixes: nodejs#63513 Signed-off-by: Mohamed Sayed <k@3zrv.com>
|
Review requested:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #63601 +/- ##
==========================================
- Coverage 90.32% 90.32% -0.01%
==========================================
Files 730 730
Lines 234669 234704 +35
Branches 43946 43968 +22
==========================================
+ Hits 211967 211987 +20
- Misses 14417 14437 +20
+ Partials 8285 8280 -5
🚀 New features to boost your workflow:
|
|
I don't think adding a check is worth it, I think the current behavior is fine actually, the spec requires a TypeError, we're throwing a TypeError (except for |
LiviaMedeiros
left a comment
There was a problem hiding this comment.
+1 on explicit ERR_INVALID_THIS over implicit private field access. Errors from private fields are misleading and not future-proof: it's too easy to break 'implicit throw' unintentionally (in fact, Navigator.prototype.language was initially introduced using private field, too).
It’s only true if that’s not covered by tests (which I would have expected WPT to cover, but I guess not, or at least not the subset we’re running) |
There was a problem hiding this comment.
In undici we are lenient with errors too with the expectation that a reviewer would notice if a change similar to the one that changed .language was made.
Since it's not reasonable here, I think the change is fine. Regarding the WPTs, brand checks should be implemented the same across globals in most platforms so the assumption is that if you have it implemented properly in one spec, it's also implemented correctly in the thousands of over browser globals.
Signed-off-by: Mohamed Sayed <k@3zrv.com>
|
Thanks for the reviews, the test now covers all getters via I'm more into keeping the explicit |
|
Here's what the error looks like on the browser side:
FWIW I'm in the Chromium camp, I think minimal effort is the appropriate amount of support we should spend on "passing an invalid |
Fixes: #63513
Add an explicit
#field in thisbrand check to each getter so a proper ERR_INVALID_THIS is thrown, matching browser behavior. This also fixeslanguage, which previously did not error at all on the prototype because it did not touch a private field.