Fix recently audible tab alert state for portals.
1. Add having any kind of inner contents that is currently audible as a qualifying condition for a contents being audible. This encompasses portals. 2. Correspondingly, add attaching/detaching an inner contents as a possible reason for the audio state changing. Detachment can happen implicitly during contents destruction (which already deals with this, and would otherwise attempt to access destructed members), so this case is excluded. 3. Currently the timeout that the tab actually observes is the one issued directly by AudioStreamMonitor, but an inner contents AudioStreamMonitor may already be destroyed (along with its owning contents) at the time the 2-second timer expires. It notifies using the navigation state signal. The outer contents RecentlyAudibleHelper is aware of the correct state, but pending the resolution of crbug.com/846374 does not notify the tab strip of this. Until that is resolved, add a notification directly from the helper. This may duplicate the AudioStreamMonitor notification, but this appears to be harmless (we'll just recompute the alert state twice) and in any event will go away when crbug.com/846374 is fixed. 4. Browser tests that watch the tab UI state are included. These tests are high-level integration tests, because tests which merely examined the recently-audible state would not have caught some issues that arose from notification of that state change not being propagated to the chrome. Fixed: 1085862 Change-Id: I9c6c7be64883914fdbfff5bf565718b108113b7f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2213118Reviewed-by:Charlie Reis <creis@chromium.org> Reviewed-by:
Kevin McNee <mcnee@chromium.org> Reviewed-by:
Chris Hamilton <chrisha@chromium.org> Commit-Queue: Jeremy Roman <jbroman@chromium.org> Cr-Commit-Position: refs/heads/master@{#773374}
Showing
chrome/browser/portal/DEPS
0 → 100644
This diff is collapsed.
Please register or sign in to comment