GitLab

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}