1409527 - Objects emulating undefined not handled properly in BCE::emitAsyncIterator

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement, P2)

Description

[Jeff Walden [:Waldo]]

obj[@@asyncIterator] is compared == to |undefined|, which lets document.all-alikes slip through.  This needs to be compared strictly against null and undefined both, as in bug 1408740 (during which bug-fixing I found this one).

Comment 1

[Jeff Walden [:Waldo]]

Attachment: Probable patch

No test upstreamed for this yet.  Depends on that other patch landing first, natch.

Comment 2

[André Bargull [:anba]]

Comment on attachment 8919555 [details] [diff] [review]
Probable patch

Review of attachment 8919555 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/frontend/BytecodeEmitter.cpp
@@ +7023,4 @@
>          return false;
>  
>      IfThenElseEmitter ifAsyncIterIsUndefined(this);
> +    if (!emitPushNotUndefinedOrNull())                            // OBJ ITERFN !UNDEF-OR-NULL

Hmm, I understand why you've chosen to use "!UNDEF-OR-NULL" here instead of "NOT-UNDEF-OR-NULL", but nonetheless I'm wondering if it's preferable to use "NOT-UNDEF-OR-NULL" for consistency...

Comment 3

[Jeff Walden [:Waldo]]

Yeah.  An arguably over-engineered solution would be to make the function *configurably* return undef-or-null or !undef-or-null by spewing stricteq/strictne and and/or as appropriate, but it seems probably overkill.

Upstream PR for a test is https://github.com/tc39/test262/pull/1299 which I tested (for future reference) using

  ./test262-update.py --local /home/jwalden/moz/test262/ --branch getiterator-async-funky

and which failed pre-patch and succeeds post-patch.

I'll push these two emulate-undefined patches once this bug's PR is merged.

Comment 4

[Jeff Walden [:Waldo]]

Landed:

https://hg.mozilla.org/integration/mozilla-inbound/rev/adf632d02408a8434d08a48bbb9776a975d1b830

There are some further quirks to this, that don't cast shade on this patch or the upstream test PR.  See bug 1408740 comment 8.  As regards this specific test, |iter[@@asyncIterator]| is called with no arguments passed, so should return null per specified HTML semantics that we don't implement, which triggers a very-slightly-later thrown TypeError.  However, the test also accepts that thrown TypeError as a success case, so the upstream PR is still a perfectly correct test, and will remain so when we fix Gecko semantics for calling |document.all|.  With that in mind, we're done here.

Comment 5

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/adf632d02408