Open Bug 1701443 Opened 3 years ago Updated 19 days ago

Favicons are hidden when media is present on page and hovering over tabstrip, making it harder to find tabs


(Firefox :: Tabbed Browser, defect, P3)




Tracking Status
firefox-esr78 --- unaffected
firefox87 --- unaffected
firefox88 --- disabled
firefox89 --- wontfix
firefox90 --- fix-optional


(Reporter: yoasif, Unassigned)


(Blocks 1 open bug, Regression)


(Keywords: nightly-community, regression, Whiteboard: [proton-tabs-bar])


(3 files)

Steps to reproduce:

  1. Set browser.proton.enabled to true
  2. Restart Firefox
  3. Open tabs in background with media on them from different sites - YouTube, Vimeo, DailyMotion, etc.
  4. Hover over tab strip

What happens:

Favicons disappear, making it harder to find the tab I am looking for.

Expected result:

I can always see the tab favicon.

47:34.92 INFO: Narrowed inbound regression window from [9a7dd526, c3fdb260] (3 builds) to [9a7dd526, 9afd696a] (2 builds) (~1 steps left)
47:34.97 INFO: No more inbound revisions, bisection finished.
47:34.98 INFO: Last good revision: 9a7dd526e56ca6c9c5a022a1aa74fa97dbc522ba
47:34.98 INFO: First bad revision: 9afd696ad2b4d6050828a59306c27a9bff724dbc
47:34.98 INFO: Pushlog:

Has Regression Range: --- → yes
Has STR: --- → yes
Regressed by: 1693066
Summary: Favicons are hidden when media is present on page, making it harder to find tabs → Favicons are hidden when media is present on page and hovering over tabstrip, making it harder to find tabs
Whiteboard: [proton-tabs-bar]

Set release status flags based on info from the regressing bug 1693066

This is by design, we decided to implement this behavior to help identify tabs where media plays.

Closed: 3 years ago
Resolution: --- → INVALID

Romain, I realized that I should have clarified the steps to reproduce a bit better - it is best to open the tabs in the background (command/control clicking). At that point, it becomes impossible to identify the site that is open upon hovering the tab strip, even though no media is playing yet.

Can this design be reviewed given the clarification of the use case and steps to reproduce?

Flags: needinfo?(rtestard)
Resolution: INVALID → ---
Attached image image.png

Adding a screenshot to show the issue.

Thanks for clarifying, I think I get the issue now.
I feel like the solution could be that we segment scenarios:

  • May tabs are opened with block autoplay: don't display the "play" button on tabs hover
  • One or a few tabs are opened with block autoplay: display the "play" button on tabs hover

This is although a rather corner case and I'll mark it as P3 given that realistically this won't block MR1 and we likely won't have time to assess a solution for 89.

Flags: needinfo?(rtestard)
Priority: -- → P3

Romain, I think it would be simpler to always show the favicon, like in release Firefox. That way you don't have to implement new logic (with new rules) for something that already works.

My own take is that the new behavior doesn't really make it easier to find tabs playing audio - I have not done much research, but I have seen that Chrome has a global media control feature: that seems far more effective, as it handles tab overflow and presumably, multiple windows.

The Proton change here doesn't help much at all, since it removes one additional way to find tabs playing audio (if I suspect that I know the site playing audio).

The favicons of tabs that play sound disappear if the locale (in this case ja) is in the list 'browser.tabs.secondaryTextUnsupportedLocales'.

The hover functionality doesn't make it better, it makes it worse.

The favicons should always be displayed.

While I would prefer to have the favicons shown all the time, I find the hiding of the favicons minor compared to the annoying flashing on the screen caused by the hiding. (Bug 1703791.)

See #1705786 - A possible solution would be to show the media playing / mute icons as a badge overlaid on top of the favicons, like is currently the case when playing picture-in-picture mode.

I assumed concrete solution suggestions should go into a separate issue, sorry about that.

As I said above, a possible solution would be to show the mute button as a badge overlaid in the top-right corner of the favicon, like currently when playing picture-in-picture mode.

This would allow to properly identify tabs playing media even if the mouse isn't hovering the tab strip, and even in compact mode.

(It seems like I can't add an attachment here, see the other issue for an illustration)

To add to the concerns raised so far, if you set to false or start playing a local video file, the speaker icon is clearly visible under the generic favicon when in PiP mode.

With the PiP indicator gone in proton, it is also impossible to locate a PiP tab (to mute/unmute) without first hovering on the tabstrip if I am on compact mode or one of the unsupported locales.

Attached image mute badge

Edit: found how to attach an illustration. Any comments on this ?

With the fix of bug 1703791 the Favicon is only hidden for the tab the mouse is over.

In 89.0b9, the speaker icon now has a weird hit area highlight (similar to that of the close tab button) when the cursor is hovering over it. I am not sure if this is intended behavior?

I don't think this is an accessibility issue, more like a general usability issue. Removing keyword.

Keywords: access
Depends on: 1713386

I think comment #14 is the way to go. I tend to have a lot of tabs open at the same time and the text below the title isn't noticeable. Also hovering over the favicon to mute feels weird to me.

You need to log in before you can comment on or make changes to this bug.