UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2859.0 Safari/537.36

Steps to reproduce the problem:
There has been a recent (unintended?) change in the behaviour of WebWorker.postMessage, which sends messages from a WebWorker to the hosting web-page.

Previously, WebWorker.postMessage behaved like a synchronous operation. When WebWorker.postMessage was called, the message was received instantaneously in the web-page message listener. After a recent change observable in Chrome 54.0.2840.16 (see bisect), this behaviour is no longer true for inactive tabs (those not in the browser foreground): there is now a variable pause in the hundreds of milliseconds between WebWorker.postMessage being called and the message being received.

I've attached an example webpage showing this new message latency. In Chrome 55.0.2859.0 Mac, I have just observed the following WebWorker.postMessage latencies:
- active tab: 1ms for all
- inactive tab: 857, 729, 978, 968, 978ms

This change will break any existing Javascript that assumes that WebWorker.postMessage is effectively a synchronous operation in all tabs. In inactive tabs, WebWorker.postMessage is now behaving asynchronously, with very inconsistent latencies.

Other latest browsers still function with WebWorker.postMessage behaving like a synchronous operation in both active and inactive tabs. Latest Firefox 48.0.2, Safari 9.1.3, and Opera 39.0.2256.71 show message latencies of 1ms.

As such, reporting this as regression bug.

Example webpage and bisect follow.

Example webpage
===============

Load the example webpage and open the console.
Click 'Start Test', and a WebWorker will call postMessage 5 times.
The console will show postMessage latency: the time between WebWorker.postMessage being called, and the message being received in the webpage.
Now try this test in an active tab, and an inactive tab (one not in the foreground). postMessage latencies are now different.

Bisect
======

Bisecting between: Google-Chrome-53.0.2785.101 and Google Chrome 54.0.2840.16 beta

https://omahaproxy.appspot.com
53.0.2785.101 (works) => 403382
54.0.2840.16 (busted) => 414607

python bisect-builds.py -a mac -g 403382  -b 414607 --use-local-cache -- file:///.../web-worker-postmessage-bug/bug.html

You are probably looking for a change made after 412336 (known good), but no later than 412353 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/96f441665a24e7d59266d1c1c3aeb154746485cf..9d09d6956024ee4765ff7933628ce6879e103cad

Possible root cause: https://chromium.googlesource.com/chromium/src/+/a1e7e84803441a117280bbf0d20e8d7479453691

What is the expected behavior?
WebWorker.postMessage effectively behaves like a synchronous operation in all active and inactive tabs. This is the case for other modern browsers.

What went wrong?
In inactive tabs, WebWorker.postMessage is now behaving asynchronously, with very inconsistent latencies.

Did this work before? Yes 53.0.2785.101

Chrome version: 55.0.2859.0  Channel: dev
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 23.0 r0
 

Deleted: bug.html 869 bytes

bug.html 869 bytes View Download

Deleted: bug.js 1.3 KB

bug.js 1.3 KB View Download