If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Placing any button before the New Tab button causes undesirable outcomes under some circumstances

NEW
Unassigned

Status

()

Firefox
Tabbed Browser
P3
normal
28 days ago
6 days ago

People

(Reporter: Itiel, Unassigned)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

28 days ago
Created attachment 8900433 [details]
Animation

Environment:
Latest Nightly
Windows 10 x86

STR:
1. Enter customization mode
2. Place any icon right before the New Tab or "List all tabs" button on the tab strip
3. Close customization mode
4. Open a new window with a number of tabs that would overflow the tab strip minus one (so for example, if 10 tabs are needed to overflow the tab strip, open 9)
5. Close the last tab, and don't move your cursor away from its X button

AR:
1. The New Tab button gets stuck at the top right (or left, for RTL users) of the tab strip, even if there's only one tab open. You may say that this is on purpose since the user explicitly did it on his own, but this applies also if you move the New Tab button before the "List all tabs" button, and in such case- the "List all tabs" button becomes invisible if the tab strip is not overflown, thus making the New Tab button stuck on the edge unreasonable.
2. After step 5 from the STR above- the cursor gets in a not clickable area as the tabs shift a little to the left (or right, for RTL users)

ER:
1. In cases where there's an invisible icon (such as [or maybe only?] the "List all tabs" button, if the tab strip is not overflown), make the New Tab button stick right next to the last tab. Otherwise, stick it in the right (or left, for RTL users) side of the tab strip alongside the other button.
2. One would expect that the tabs would get expanded to a point where the next click would also close the next tab. This is the behaviour if there's no button before the New Tab button.

See attached animations for better explanation for issue #2.

Comment 1

28 days ago
Something weird is going on here with tab resizing / scrolling. I hope the folks who worked on bug 1356705 and similar have ideas here.
Component: Toolbars and Customization → Tabbed Browser
Whiteboard: [photon-visual][triage]

Updated

28 days ago
Whiteboard: [photon-visual][triage]
(In reply to ItielMaN from comment #0)
> AR:
> 1. The New Tab button gets stuck at the top right (or left, for RTL users)
> of the tab strip, even if there's only one tab open. You may say that this
> is on purpose since the user explicitly did it on his own, but this applies
> also if you move the New Tab button before the "List all tabs" button, and
> in such case- the "List all tabs" button becomes invisible if the tab strip
> is not overflown, thus making the New Tab button stuck on the edge
> unreasonable.

FWIW, this is entirely expected behavior.

> 2. After step 5 from the STR above- the cursor gets in a not clickable area
> as the tabs shift a little to the left (or right, for RTL users)

Let's keep this bug focused on this issue. Is this a regression?
Flags: needinfo?(itiel_yn8)
See Also: → bug 1387171
(Reporter)

Comment 3

28 days ago
(In reply to Dão Gottwald [::dao] from comment #2)
> > 2. After step 5 from the STR above- the cursor gets in a not clickable area
> > as the tabs shift a little to the left (or right, for RTL users)
> 
> Let's keep this bug focused on this issue. Is this a regression?

Yes, from a VERY long time ago: 2013-11-17 to 2013-11-18, though I can't pinpoint the exact patch that did this (Mozregression threw off a message "Unable to find enough data to bisect").
If I'm not mistaken this was the exact dates that Nightly switched to the Australis design.
Flags: needinfo?(itiel_yn8)
(Reporter)

Updated

28 days ago
Has Regression Range: --- → yes
Keywords: regression
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.