s/visiblity: none/display: none/.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

I believe this is still an issue.

I can confirm comment #4 by running the following test:

1- Log the calls to WillBeginCompositorFrame (tracing should help but I simply printf-ed)

2- Open a page with an OOPIF.
3- Navigate OOPIF to page which runs javascript and changes something, such as the value of some <input>.
4- Observe that WBCF is being called constantly.
5- Now hide the frame by either 'visibility:hidden' or 'display:none' and observe that WBCF is no longer called.
6- Switch tabs, or, navigate the OOPIF to the same page again.
7- Observe that WBCF is being called again (for the OOPIF).

The fix for this seems simple so I will put up a CL and see how bots look like. to be specific, in RWHCF::Show we should check with CPFC to see if the frame owner element is visible. We already have that information (we don't keep it right now) from FrameMsg_VisibilityChanged.

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

commit c248388ee52dfcff241e5b1d6dc69637eb3c7c40
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Tue Aug 01 18:58:54 2017

Track CSS visibility state of OOPIFs on the browser side

When an OOPIF is hidden through changing CSS properties of its frame-
owner element, the state is reported to the browser and the IPC handled
in the CrossProcessFrameConnector associated with RWHV. This will also
lead to a call to RenderWidgetHostImpl::WasShown/WasHidden for the
corresponding local root.

However, when the browser is shown all RWHVs are asked to Show which
will invalidate the current state of CSS visibility. Specifically, this
causes a hidden frame to generate compositor frames.

This CL will add a bit to RenderWidgetHostViewChildFrame to remember its
CSS visibility state. Also when RWHVCF::Show is called, the view will
verify that neither itself nor an ancestor view are CSS invisible before
calling RenderWidgetHostImpl::WasShown.

BUG= 628700 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: I42c3d7f50aacd47b12f0de151c856233e8942510
Reviewed-on: https://chromium-review.googlesource.com/583729
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491066}
[modify] https://crrev.com/c248388ee52dfcff241e5b1d6dc69637eb3c7c40/content/browser/frame_host/cross_process_frame_connector.cc
[modify] https://crrev.com/c248388ee52dfcff241e5b1d6dc69637eb3c7c40/content/browser/frame_host/cross_process_frame_connector.h
[modify] https://crrev.com/c248388ee52dfcff241e5b1d6dc69637eb3c7c40/content/browser/frame_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/c248388ee52dfcff241e5b1d6dc69637eb3c7c40/content/browser/frame_host/render_widget_host_view_child_frame.h
[modify] https://crrev.com/c248388ee52dfcff241e5b1d6dc69637eb3c7c40/content/browser/site_per_process_browsertest.cc
[add] https://crrev.com/c248388ee52dfcff241e5b1d6dc69637eb3c7c40/content/test/data/counter.html

Closing the bug following comment #7.