xaansodi@ Thanks for the issue.

Tested this issue on Mac OS 10.13.6 on the reported version 70.0.3538.77, latest Canary 72.0.3605.0 and M-69(69.0.3497.100) build by following the below steps.

1. Launched Chrome and opened the given html file.
2. Navigated to console of the iframe and executed the code provided in raf.js file.
3. Could observe that the calls to requestAnimationFrame is not slowing down when we changed the tabs and minimize the browser.
The same behavior is observed on M-69 build.
Attached are the screen casts for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.
Also request you provide the screen cast of the issue observed which will help in better understanding of the issue.

Thanks..

Deleted: 903455-M70.mp4 1.7 MB

	903455-M70.mp4 1.7 MB View Download

Deleted: 903455-M69.mp4 2.0 MB

	903455-M69.mp4 2.0 MB View Download

Hi susan.boorgula@, thanks for looking into this.

I am sorry, I think I forgot to add one step. You need to undock the dev tools so that you can see what is happening during the time that you switch tabs or minimize the browser. I have attached my screen cast to demonstrate this.

You will observe that when you switch tabs, requestAnimationFrame does indeed slow down (even stops), while when you minimize the browser, the calls do not slow down.

I do not have Chrome 69 in this machine, but when I tested it a few days ago, requestAnimationFrame does work correctly, i.e. it slows down when you minimize the browser.

Deleted: raf_failing.mp4 1.5 MB

	raf_failing.mp4 1.5 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Not sure if Blink>Scheduling is right. Looks like we need a bisect though.

xaansodi@ Thanks for the update.

Able to reproduce this issue on Mac OS 10.13.6 on the reported version 70.0.3538.77 and latest Canary 72.0.3608.0.
Unable to reproduce the issue on Windows 10 and Ubuntu 17.10

Bisect Information:
===================
Good Build: 70.0.3526.0
Bad Build : 70.0.3527.0

By running per-revision script below is the ChangeLog URL 
https://chromium.googlesource.com/chromium/src/+log/8dd71fb5aa8e03b207033330071b3c8b704b2ea4..7f0134a1a8bd234e534bfbd3e8939a9d2a068a00

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/1180536

alph@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Adding 'ReleaseBlock-Stable' for M-70 as this is a recent regression. Please feel free to remove if it is not applicable.

Thanks..

It has nothing to do with my patch. The code in the patch is not executed during the repro steps.

Can you please try bisecting it once more.

Reminder M71 Stable is approaching VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thank you.

Requesting to take a look at M71 blockers ASAP due to upcoming Thanksgiving holidays next week.

In reply to comment #8, run the bisect scrip again and below is bisect information.

Bisect Information:
===================
Good Build: 70.0.3525.0
Bad Build : 70.0.3526.0

By running per-revision script below is the ChangeLog URL 
https://chromium.googlesource.com/chromium/src/+log/41b5b795832626a12a410e1956028a8d53b8e163..f6a6fa6c2133597586b8e698fe771d71d44a2f33

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/1178622

lukasza@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks..

+fdoray@ in case this is related to window occlusion, seeing as this is mac-only.

fsamuel@, can you PTAL and help triage further?  I don't know enough about rAF and how it gets throttled to start investigating why it doesn't work with OOPIFs on Mac :-/.

r584254 blamed in #c10 simply makes site-per-process the default on desktop.  I wonder if OOPIFs are missing some information that should trigger throttling of rAF

+danakj@ who looked at how OOPIF-related widgets work (shooting in the dark / not sure if this might be related to the problem at hand).

Passing along to samans@

It turns out that minimizing the Window on Mac will end up in RenderWidgetHostView::WasOccluded which is not implemented for child frames. I can confirm hiding the view in the override fixes this issue. I cannot confirm that is the right fix yet since I don't quite know why "occluded" is supposed to be.

ccameron, do you happen to be familiar with how visibility is propagated to child frames on Mac?

Reminder M71 Stable is approaching VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thank you.

Requesting to take a look at M71 blockers ASAP due to upcoming Thanksgiving holidays next week.

As this is regressed in M70, not a blocker for M71. Pls target fix for M72.

Friendly ping to look into this issue and to provide further update on this issue as it has been marked as a stable blocker.

Thanks!

Do you think this issue is related to this other one?
 
https://bugs.chromium.org/p/chromium/issues/detail?id=865192#c5

The "was occluded" state means that the tab may still draw its last contents (so it is "visible"), but the web contents should not think that it is visible.

The reason for this state is that, when minimized, we still need to be able to "draw" our window, e.g, for exposé.

I have a hunch that all of this can be removed now, because that "need to draw" is now pushed over into MacViews.

There is also a question as to what the correct behavior is WRT OOPIF.

Friendly ping to look into this issue and to provide further update on this issue as it has been marked as a stable blocker.

Thanks!

Friendly ping to look into this issue and to provide further update on this issue as it has been marked as a stable blocker.

Thanks!

This does look similar to issue 865192, but that issue is not a recent regression.

ccameron@: What question did you have about the intended behavior for OOPIFs?  Presumably they should behave the same as in-process iframes, in terms of requestAnimationFrame throttling.  kenrb@ and/or chrishtr@ might be able to answer more specific questions about expected behavior if that helps spot or fix the bug.

Re #21, this actually looks to be used in lots of places.

ekaramad@, let's go ahead with your patch from #15 -- it sounds like the right thing to do.

CL in progress: 1357303

Friendly ping to get an update as it is marked as RB stable.
Thanks..!

A CL is under review.
https://chromium-review.googlesource.com/c/chromium/src/+/1357303

Thanks.

ekaramad@ do you think your change also solves issue 865192

https://bugs.chromium.org/p/chromium/issues/detail?id=865192#c5

which is about document.hidden not working/propagating on cross-domain iframes?  

It probably won't. My patch changes the visibility of RenderWidget which apparently affects the throttling here; the visibility API is more of a RenderView thing.

I wonder if danakj@'s patch #613740 should fix issue 865192.

That patch removes an IPC that is not needed anymore. Previous work in https://bugs.chromium.org/p/chromium/issues/detail?id=908582#c24 disconnected page from widget visibility, so may address it? You could re-test on TOT.

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

commit a03e1580f9da8b52104e67b227af8342c5ce99d8
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Wed Dec 05 23:07:56 2018

Hide RenderWidgetHostViewChildFrame if Occluded

The RenderWidgetHostView::WasOccluded and ~::WasUnOccluded are not overridden. On MacOSX minimizing
the browser leads to calling WebContents::WasOccluded which is therefore not triggering the
visibility of child RenderWidgets.

This CL implements the methods for RWHVCF and adds a test which verifies requestAnimationFrame is
throttled for occluded child renderer processes.

Bug:  903455 
Change-Id: If836a872e6372abf31017cc81dcaa3e7d31d65b9
Reviewed-on: https://chromium-review.googlesource.com/c/1357303
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614162}
[modify] https://crrev.com/a03e1580f9da8b52104e67b227af8342c5ce99d8/content/browser/renderer_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/a03e1580f9da8b52104e67b227af8342c5ce99d8/content/browser/renderer_host/render_widget_host_view_child_frame.h
[modify] https://crrev.com/a03e1580f9da8b52104e67b227af8342c5ce99d8/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/a03e1580f9da8b52104e67b227af8342c5ce99d8/content/browser/web_contents/web_contents_impl.cc
[add] https://crrev.com/a03e1580f9da8b52104e67b227af8342c5ce99d8/content/test/data/page_with_raf_counter.html

Removing unneeded labels. Marking as fixed following comment #35 and adding a request to merge to M72.

Your change meets the bar and is auto-approved for M72. Please go ahead and merge the CL to branch 3626 manually. Please contact milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop)

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

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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/+/9964b3f54f8c632c24b5cb4896e2e0021be2a8e3

commit 9964b3f54f8c632c24b5cb4896e2e0021be2a8e3
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Mon Dec 10 18:15:48 2018

Hide RenderWidgetHostViewChildFrame if Occluded

The RenderWidgetHostView::WasOccluded and ~::WasUnOccluded are not overridden. On MacOSX minimizing
the browser leads to calling WebContents::WasOccluded which is therefore not triggering the
visibility of child RenderWidgets.

This CL implements the methods for RWHVCF and adds a test which verifies requestAnimationFrame is
throttled for occluded child renderer processes.

TBR=ekaramad@chromium.org

(cherry picked from commit a03e1580f9da8b52104e67b227af8342c5ce99d8)

Bug:  903455 
Change-Id: If836a872e6372abf31017cc81dcaa3e7d31d65b9
Reviewed-on: https://chromium-review.googlesource.com/c/1357303
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#614162}
Reviewed-on: https://chromium-review.googlesource.com/c/1370199
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#211}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/9964b3f54f8c632c24b5cb4896e2e0021be2a8e3/content/browser/renderer_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/9964b3f54f8c632c24b5cb4896e2e0021be2a8e3/content/browser/renderer_host/render_widget_host_view_child_frame.h
[modify] https://crrev.com/9964b3f54f8c632c24b5cb4896e2e0021be2a8e3/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/9964b3f54f8c632c24b5cb4896e2e0021be2a8e3/content/browser/web_contents/web_contents_impl.cc
[add] https://crrev.com/9964b3f54f8c632c24b5cb4896e2e0021be2a8e3/content/test/data/page_with_raf_counter.html

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

Commit: 9964b3f54f8c632c24b5cb4896e2e0021be2a8e3
Author: ekaramad@chromium.org
Commiter: ekaramad@chromium.org
Date: 2018-12-10 18:15:48 +0000 UTC

Hide RenderWidgetHostViewChildFrame if Occluded

The RenderWidgetHostView::WasOccluded and ~::WasUnOccluded are not overridden. On MacOSX minimizing
the browser leads to calling WebContents::WasOccluded which is therefore not triggering the
visibility of child RenderWidgets.

This CL implements the methods for RWHVCF and adds a test which verifies requestAnimationFrame is
throttled for occluded child renderer processes.

TBR=ekaramad@chromium.org

(cherry picked from commit a03e1580f9da8b52104e67b227af8342c5ce99d8)

Bug:  903455 
Change-Id: If836a872e6372abf31017cc81dcaa3e7d31d65b9
Reviewed-on: https://chromium-review.googlesource.com/c/1357303
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#614162}
Reviewed-on: https://chromium-review.googlesource.com/c/1370199
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#211}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}