Promise microtask queue flushed on misc document write
Reported by
logan.f....@gmail.com,
Apr 26 2016
|
|||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.22 Safari/537.36
Steps to reproduce the problem:
Run the following snippet:
```
var sync = true;
Promise.resolve().then(() => {
console.log(sync);
});
var doc = new DOMParser().parseFromString('hi', 'text/html');
sync = false;
```
What is the expected behavior?
The promise should log "false" because the promise callback is should be in the microtask queue.
What went wrong?
It logs "true" because it appears
```
var doc = new DOMParser().parseFromString('hi', 'text/html');
```
or
```
var doc = document.implementation.createHTMLDocument();
doc.open();
doc.write('hi');
doc.close();
```
cause the promise queue to be flushed when `doc.close()` is called.
Did this work before? Yes Chrome 50
Chrome version: 51.0.2704.22 Channel: beta
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 21.0 r0
,
Apr 28 2016
Thanks for the report.. Bisect Info: CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/b3b718dbd360c8159ed62973b3bd10a99d67eabe..92a2678f7095597093128d486fc750e16e3c7666 yhirano@, could you please check and help us in finding an owner it its not yours. Broken in M51, Able to reproduce the issue on Win7, Mac OS X 10.11.4, Ubuntu using Chrome Beta 51.0.2704.29, Dev 52.0.2716.0 and Canary 52.0.2718.0 Good Build: 51.0.2682.0 Bad Build : 51.0.2683.0 Bad Build:
,
Apr 28 2016
When I load the attached html with Chrome 51.0.2704.29 beta (64-bit), it prints "false". Am I missing something?
,
Apr 28 2016
I didn't realize this when I originally filed, sorry, that's what I get for not making a standalone HTML example. I just took another look and this only appears to happen when triggering the code from inside the console, or from Selenium's executeFunction. We started seeing it because all of our selenium tests started failing, and I proceeded to debug from my console. Doh.
,
Apr 28 2016
Is https://chromium.googlesource.com/chromium/src/+/07892da08747cb20df3856387961dff5f4902cf3 related? kozyatinskiy@, can you take a look?
,
Apr 29 2016
I think that it doesn't related to my CL but I've prepared speculative fix. https://codereview.chromium.org/1933033002/
,
May 2 2016
This is all caused by crbug.com/425790 workaround. Let me see if it is possible to remove the workaround again.
,
May 5 2016
,
May 10 2016
Is there any realistic chance of this regression not going Beta to Stable in the next release at this point?
,
May 16 2016
This appears to be working again in 51.0.2704.47, FYI.
,
Jun 1 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 21 2016
I think this is the correct semantics here, we're supposed to queue a task for the DOMContentLoaded in the spec IIRC. Right now we do the load event and a bunch of things inside the same task, when there should be separate tasks for each.
,
Jul 12 2016
This issue has been moved once and is lower than Pri-1. Removing the milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 17
This seems to have been fixed as of M68. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by yutak@chromium.org
, Apr 28 2016Owner: yhirano@chromium.org
Status: Untriaged (was: Unconfirmed)