Able to repro the issue on mac 10.11.6 win10 and Linux 14.04 chrome version 52.0.2743.116 and canary

Below is the bisect info

Good Build: 52.0.2742.0
Bad Build: 52.0.2743.0

You are probably looking for a change made after 394860 (known good), but no later than 394886 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/6b693cb69c1731ac3e4fa0851e64fd10fa820a1c..003cd61ab7a3e38d8f7fdfe55068c5450ed1bb68

Possible suspect : https://codereview.chromium.org/1931793002

aelias@, is this working as intended?

FYI, safari shows the same behavior as we do.

Yes, this seems like the expected behavior.  alert is immediately blocking whereas painting posts asynchronous tasks, and we intentionally changed not to run any tasks on the main message loop while the alert is active.

This change is documented at https://www.chromestatus.com/features/5683408571203584 , for reference.

Drat!!!! I'd developed a bunch of online JavaScript projects that relied on printing messages to a console in between alert boxes appearing... going to be a real pain to change all those lessons.

For now we've just had to tell people to use Firefox or Edge.

I guess that's the risk you take with web development!!

It also broke our python course that uses Brython, which implements input using prompts... and print by printing to the console. We try to display console messages in an element on the webpage... but they won't display in between prompt messages.

I guess the only work around for this is to tell people they have to use Firefox? Since completely rewriting our Python courses is not really an option at this stage.

So what is the rationale behind having an alert box blocking changes to the dom that occurred on the previous line of code?

Sorry, I realize the behavior is surprising -- the root cause is that alert() is an odd duck in the web platform to begin with.  The rationale is the portion of the spec about event loops: https://html.spec.whatwg.org/multipage/webappapis.html#event-loop .

When you modify the DOM, although the change to the DOM itself is instantaneous, actually painting it to the screen is posted as a task/microtask on the loop to be run after your JS yields.  This is an essential optimization to avoid multiple paint passes when JS touches a lot of DOM at once, shared among all browsers.

What changed in Chrome M52 is that alert(), which is a immediately run "paused task", now better conforms to the spec text: "While a user agent has a paused task, the corresponding event loop must not run further tasks, and any script in the currently running task must block."  On Firefox, IE and Chrome <=51, there is a special "nested event loop" that runs more tasks inside paused tasks, which we removed.  This conforms with Safari's behavior and other browser vendors may eventually also follow.


Anyway, I'm sorry we broke your online course with this change.  A workaround to keep using Chrome would be to post messages using "console.log()" and ask your students to use Chrome developer tools "Console" instead of your custom display.  Note that this workaround would also be needed for Safari.  I'd understand if you don't consider this satisfactory and prefer to recommend Firefox, though.

Another easy workaround for alert() and prompt() in this case is to use modal dialog such as this: http://jqueryui.com/dialog/#modal

Right, although such alert polyfills are nonblocking, so they might not be satisfactory if the intent is to interrupt the JS execution for instructional purposes.  The ideal solution would be to use such a polyfill in combination ES7 async await, although that's very cutting edge for now (only implemented by Chrome 53 behind --enable-experimental-web-platform-features flag: see https://www.chromestatus.com/feature/5643236399906816 ).

Yeah, the lessons rely on the blocking functionality.

I am eagerly awaiting await... as that will be a good solution...

A shame about the timing of this change! The first of the courses have been
around for almost 5 years without issue on Chrome, FF, IE, Edge...

Does anyone have any idea when await will be available without the
experimental flag?? Once that's available, we can use that for Chrome, and
keep the existing approach in FF, IE, Edge.

Mike

And thanks so much for the detailed replies! I wasn't expecting such
helpful responses!

Sure, explaining the reason is the least we can do.

> Does anyone have any idea when await will be available without the
experimental flag??

There's no predetermined schedule, the only answer I can give is "when it's finished".  You can follow the progress on https://bugs.chromium.org/p/v8/issues/detail?id=4483 and https://www.chromestatus.com/feature/5643236399906816

 Issue 648206  has been merged into this issue.