1701976 - Hard to see that there are more tabs at the ends of the tab strip

Status: REOPENED

(Firefox :: Tabbed Browser, defect, P5)

Description

[Asif Youssuff]

Attachment: image.png

Steps to reproduce:

1. Set browser.proton.enabled to true
2. Restart Firefox
3. Open many tabs (enough that the tab strip overflows)

What happens:

It looks like the tabs end and do not continue offscreen.

Expected result:

Something like prior to bug 1693795.

7:38.89 INFO: No more integration revisions, bisection finished.
7:38.89 INFO: Last good revision: 5a9e649ae7dca860ac85034f45f919e2ca9be4f2
7:38.89 INFO: First bad revision: 07e1fb85f61af92ca36d0961caa5b198daf1a32d
7:38.89 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5a9e649ae7dca860ac85034f45f919e2ca9be4f2&tochange=07e1fb85f61af92ca36d0961caa5b198daf1a32d

Comment 1

[Romain Testard [:RT]]

Aaron can you please help prioritize this one?

Comment 2

[Romain Testard [:RT]]

I talked to Aaron, we agree that this is not a Proton regression given same happens on release currently and this is intended.
Marking as "Won't Fix"

Comment 3

[Asif Youssuff]

Attachment: release firefox

I don't see this in release, this seems like a Proton regression to me. It doesn't even appear in Nightly if Proton isn't enabled.

Comment 4

[Asif Youssuff]

I don't see this in release.

Comment 5

[WaltS48 [:walts48]]

Each image shows the > which isn't there until the tabs overflow and users should know that there are more tabs.

Comment 6

[Aaron Benson]

Yeah I'm having a hard time discerning what the bug is here. Both cases show the tab overflow via the arrow and the shadow that the tab is flowing "beneath" the tab bar space.

Comment 7

[Asif Youssuff]

Attachment: image.png

Aaron, the easiest way to see the issue is to have the active tab be the rightmost visible tab. In the attached image, you can see that the tab overflow shadow seems to be part of or merged with the Proton tab shadow. It is really hard to visually see that there is an additional shadow, or an overflow.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 9

[Asif Youssuff]

Romain, what would an acceptable patch look like?

It seems to me that since the old overflow didn't have this issue, that it'd be simpler to not regress here than to ask for a patch.

Comment 11

[Romain Testard [:RT]]

(In reply to Asif Youssuff from comment #9)

Romain, what would an acceptable patch look like?

It seems to me that since the old overflow didn't have this issue, that it'd be simpler to not regress here than to ask for a patch.

I'm unsure, Amy can you please confirm if a different shadow treatment on first and last tabs in this situation would be desirable?

Comment 12

[Amy Lee [:amylee] UX]

I'm not sure if Aaron has something specific in mind for the shadow treatment for first and last tabs. I'll have him confirm.

Comment 13

[Aaron Benson]

(In reply to Asif Youssuff from comment #7)

Created attachment 9212578 [details]
image.png

Aaron, the easiest way to see the issue is to have the active tab be the rightmost visible tab. In the attached image, you can see that the tab overflow shadow seems to be part of or merged with the Proton tab shadow. It is really hard to visually see that there is an additional shadow, or an overflow.

Ah, yes I see what you're referring to. Unfortunately there's no way to account for the cases when the window width and tab count end up positioning shadows in close relationship with each other. The overflow arrows are meant to provide the signal to the user that there is overflow on the left or right hand side of the tab strip. The shadow is really just a visual effect to convey layering of the UI elements.

Comment 14

[Asif Youssuff]

There may not be a way to account for these weird cases, but the example I gave is just the worst case I have seen with the new design. I never ran into this issue with the old design, so I would prefer that we simply not regress here.