1759221 - New tab animation origin point is above the tab to the left

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[Dan Ceban [:okazki98]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Open a new tab

Actual results:

The new tab starts to appear above the last tab. In other words, the new tab's origin is above the last existing tab's "X" (close button), and then moves to the right.
Recording of the described issue (recommended to put video on loop): https://youtu.be/CerxMZX1O-A

Expected results:

The new tab's origin point should be the "+" (open a new tab button).
I tested this in another browser, which is a fork of Firefox ESR, and the issue cannot be reproduced there.
Some comparison screenshots of new tab origin point between current Firefox v98, and ESR: https://drive.google.com/drive/folders/1WkmX36IGSDmsmSFSy8nQfmsKGwVw1mZN?usp=sharing

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

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

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Simona Badau, Desktop QA, PTO 22-30June]

Attachment: new tab in Firefox 98.jpg

Setting this to NEW as I was able to reproduce it on the latest Nightly 100.0a1 and Firefox 98 on Windows 10 x64. While opening new tabs, it is noticeable that the new tab covers shortly the closing "X" button of the tab on the left.

I could not reproduce this issue on Firefox 91.7.1 esr, I'll look into a regression window as soon as possible.

Comment 4

[Simona Badau, Desktop QA, PTO 22-30June]

Narrowed regression window to:

Last good revision: 086074bf3060f2d150bf7818a1b388466e32ad25
First bad revision: 62f8cfde71230c04255e8a645786b808a791dabe

Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=086074bf3060f2d150bf7818a1b388466e32ad25&tochange=62f8cfde71230c04255e8a645786b808a791dabe

Comment 5

[Daniel Holbert [:dholbert]]

bug 1751484 removed a 25ms-long visibility CSS transition; it shouldn't have affected positioning in any way.

I would guess that this bug was present before bug 1751484 (i.e. the tabs were overlapping), but it wasn't perceptible because it was happening during the brief period in which the new tab had visibility:hidden (from the transition).

Comment 6

[Dão Gottwald [:dao]]

Should we reconsider bug 1751484? Could we hide only the favicon since that part is more obviously visible?

Comment 7

[Emilio Cobos Álvarez [:emilio]]

I'd much rather fix the underlying issue which is that the fade-in animation doesn't really work as expected? In particular, we're transitioning from min-width: 0.01px to min-width: var(--tab-min-width), but the stack doesn't shrink so it overflows, this is easy to check tweaking a few rules with the inspector so that they match the animation start, screencast incoming.

In terms of what's the preferred approach, I'm not sure. We could make stuff really shrink. A bit easier, we could also have the tabs have overflow: clip, which would prevent the underlying stack from being visible when it overflows... Do you have thoughts on the preferred approach?

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Attachment: Screencast from going through the relevant elements.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Ah, I think I have a better approach, perhaps...

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1759221 - Don't transition min-width in tab open animation. r=dao

In practice the min-width is always seen because of the underlying stack
sizing. So make sure that the tab doesn't wrongly go under it so that
stuff doesn't overflow to the left.

This should preserve the feel of the animation, but the tab should start
correctly positioned.

Comment 11

[Dão Gottwald [:dao]]

Not sure what's better either, I'd have to try it out. Your current approach seems fine if we can get the closing animation fixed. Using overflow: clip seems to make sense too. I think I tried that with overflow: -moz-hidden-unscrollable years ago but it didn't work at the time.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1759221 - Use -moz-box-pack: start on tabs. r=dao

So that overflowing content overflows always towards the end, rather
than getting centered.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b360d0fa4d48
Use -moz-box-pack: start on tabs. r=dao

Comment 14

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/b360d0fa4d48

Comment 15

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

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9272126 [details]
Bug 1759221 - Use -moz-box-pack: start on tabs. r=dao

Beta/Release Uplift Approval Request

• User impact if declined: Tab animations might look slightly off.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Single-line CSS fix.
• String changes made/needed: none

Comment 17

[Dianna Smith [:diannaS]]

Comment on attachment 9272126 [details]
Bug 1759221 - Use -moz-box-pack: start on tabs. r=dao

Approved for 100.0b8

Comment 18

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c0b5da46ce72

Comment 19

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I managed to reproduce this issue on Firefox 98.0(20220304153049) on Win10 64-bits. Confirmed as fixed on Firefox 100.0b8(20220419190903) and 101.0a1(20220419214607) on Win10 64-bits, macOS 11 and Ubuntu 20.04.