Tested this issue on Windows-10 using chrome latest stable M55-55.0.2883.87 by following steps mentioned in the original comment, Observed there is a delay in receiving postmessage evt data under console.

Tested the same issue on M54 54.0.2786.0 & 54.0.2832.0 and observed the same behavior over there. Unable to receive the Iframe postMessage in a second or more than 5 seconds. 

carinaelena@ Attaching the screen-shot for reference, Could you please let us know what's the actual behavior seen on  M54? Any idea exactly on which version it used to work?

Thanks!

Deleted: 684947.PNG 118 KB

	684947.PNG 118 KB View Download

See  issue 616519 . Chrome aligns timers of backgrounded tabs to 1Hz (i.e. 1 event per second). In Chrome 57 throttling starts 10 second after backgrounding the page (in Chrome 55 throttling started immediately after backgrounding). You can disable this behavior (see issue 485425) by running chrome --disable-background-timer-throttling

This isn't an issue regarding throttling of timers, rather postMessage seems to be throttled as well... I attached an image of what I am seeing in Chrome 55. Chrome 54 behavioor aligns with the screenshot attached by @brajkumar

Deleted: Capture.PNG 41.0 KB

	Capture.PNG 41.0 KB View Download

BTW...deltas shown are in milliseconds 

Maybe it's the result of  issue 487937  "Throttle the entire rendering pipeline for out-of-view cross origin frames"

In this case, the frames are in view

Added a show/hide link to take the iframe off-screen to show that this is not the case.

haraken@ did we move the post message tasks to the timer queue?

For worker->document postMessage, TaskType::PostedMessage[1] is used. This task is queued into TimerTaskRunner[2]. 

[1] https://chromium.googlesource.com/chromium/src/+/06f260832ead33668b4fa5a64074fb8a158b127f/third_party/WebKit/Source/core/workers/InProcessWorkerObjectProxy.cpp#70
[2] https://chromium.googlesource.com/chromium/src/+/1174657e747a79abfc910fdd863552562ccfc8da/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp#28

For document<->frame postMessage, Timer class is used[3] and its task is also queued into TimerTaskRunner[4].

[3] https://chromium.googlesource.com/chromium/src/+/a980b812f2f213270551f986fc7c4fdf0cc2d3a8/third_party/WebKit/Source/core/frame/LocalDOMWindow.cpp#621
[4] https://chromium.googlesource.com/chromium/src/+/4dbdb0dd364c7ac324c731004d1ccc69e3bdf2e2/third_party/WebKit/Source/platform/Timer.cpp#141

Sami, Altimin: What should we do here? Maybe should we map TaskType::PostMessage to an unthrottled task runner? Or should we push altimin's timer-task-queue-split forward?

I think that we need to revise task mapping and map TaskType::PostMessage (and maybe others) to unthrottled task runner as an immediate measure (M56?). Timer-task-queue-split will happen no earlier than M58.

Yeah, the best short term fix is probably to move both types of postMessages to an unthrottled task runner. nhiroki@, can you help with this part?

Longer term we should consider throttling these tasks again either with an opt-out or a way to detect that the tab is doing meaningful work in the background (e.g., it has a real time network connection).

In parallel we'll also improve our CPU time instrumentation which should help establish how urgent it is to throttle these types of tasks.

How about other TaskTypes that can be used for background operations, for example, TaskType::WebSocket and TaskType::DatabaseAccess? Do we move them to the unthrottle task runner, too?

Assuming the motivation of the timer throttling is to reduce unneeded polling or GUI refresh on a background tab.
So, IMO, we can map a TaskType to non-timer task runner if the task type is not related to GUI and its throttling expected not to reduce the total amount of CPU time.
Namely, RemoteEvent, Microtask, WebSocket, PostedMessage, FileReading, and DatabaseAccess? To be discussed.

I'm not sure GUI-relatedness is a good discriminator: if the work being done isn't observable by the user, why should we let it run? Android and iOS are very strict about limiting what backgrounded activities can do, and we may need to be similarly strict to actually reduce power usage.

Just in case, I'm talking about the immediate measure on c#13. For longer term, throttling task types other than realtime communication and audio sounds reasonable to me.

I'm a bit confused about why we move only postMessage to the unthrottled task runner as the immediate measure here. Why don't we move others? Is only postMessage being accidentally throttled? (Note that other tasks like WebSocket and DatabaseAccess are also posted to the timer task runner)

CL: https://codereview.chromium.org/2669883003/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/04055dd2786e27cde8d210b68e7a726fab6d0c42

commit 04055dd2786e27cde8d210b68e7a726fab6d0c42
Author: nhiroki <nhiroki@chromium.org>
Date: Sun Feb 05 04:05:05 2017

Scheduler: Enqueue non-JS-timer tasks into the unthrottled task runner

We found throttling some of non-JS-timer tasks may break existing web pages,
so this CL tentatively makes them unthrottled.

In addition, this CL switches a task type for PostMessageTimer from
TaskType::Timer to TaskType::PostedMessage because the timer is used only for
performing postMessage() and actually not used as a JS timer.

BUG= 684947 

Review-Url: https://codereview.chromium.org/2669883003
Cr-Commit-Position: refs/heads/master@{#448173}

[modify] https://crrev.com/04055dd2786e27cde8d210b68e7a726fab6d0c42/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
[modify] https://crrev.com/04055dd2786e27cde8d210b68e7a726fab6d0c42/third_party/WebKit/Source/core/frame/LocalDOMWindow.cpp

My fix was landed in...

$ git find-releases 04055dd2786e27cde8d210b68e7a726fab6d0c42
commit 04055dd2786e27cde8d210b68e7a726fab6d0c42 was:
  initially in 58.0.3004.0

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91f69c5c73122c96f0690490d09b176526bf975b

commit 91f69c5c73122c96f0690490d09b176526bf975b
Author: Hiroki Nakagawa <nhiroki@chromium.org>
Date: Tue Feb 07 11:04:22 2017

[Merge to M57] Scheduler: Enqueue non-JS-timer tasks into the unthrottled task runner

We found throttling some of non-JS-timer tasks may break existing web pages,
so this CL tentatively makes them unthrottled.

In addition, this CL switches a task type for PostMessageTimer from
TaskType::Timer to TaskType::PostedMessage because the timer is used only for
performing postMessage() and actually not used as a JS timer.

BUG= 684947 

Review-Url: https://codereview.chromium.org/2669883003
Cr-Commit-Position: refs/heads/master@{#448173}
(cherry picked from commit 04055dd2786e27cde8d210b68e7a726fab6d0c42)

Review-Url: https://codereview.chromium.org/2679083002 .
Cr-Commit-Position: refs/branch-heads/2987@{#359}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/91f69c5c73122c96f0690490d09b176526bf975b/third_party/WebKit/Source/core/dom/TaskRunnerHelper.cpp
[modify] https://crrev.com/91f69c5c73122c96f0690490d09b176526bf975b/third_party/WebKit/Source/core/frame/LocalDOMWindow.cpp

This is too late for M56, which has already launched to Stable, the user impact and that this is a long standing issue doesn't justify doing an emergency merge.  Let's wait until M57