1477461 - Closing a tab moves all the tabs while the mouse is still on the tab-bar

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180720220116

Steps to reproduce:

open enough tabs such that closing a tab will move the tabs in the tab-bar
1. Close a tab


Actual results:

All the tabs will move while the mouse is still on the tab-bar


Expected results:

the tabs should move only when the mouse leaves teh tab-bar
This is a very recent regression

Comment 1

[Mayank Bansal]

Attachment: bandicam 2018-07-21 13-12-38-810.mp4

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ffb7a39759332c492c681568017c57ed477179ba&tochange=3f1a38fec70bb43c233800a852b7dd6745262fe4

Regressed by:  3f1a38fec70b	Mike Conley — Bug 1362569 - Don't flush layout when locking the tab size during tab close. r=dao:

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Are you able to reproduce this if you close the tabs with the close icon (the X)?

Comment 4

[Alice0775 White]

(In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from comment #3)
> Are you able to reproduce this if you close the tabs with the close icon
> (the X)?

I can reproduce the issue eve if click on x button.


At least, I can reproduce on Windows10 and Linux.

Comment 5

[Mayank Bansal]

(In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from comment #3)
> Are you able to reproduce this if you close the tabs with the close icon
> (the X)?


it still repros with closing with the X button. 
(However, I think it happens for the first or the second time I close the tabs that way, and then the tabs close/reflow in the old behaviour.)

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Okay, I can reproduce this. Looks like this is the result of the switch from the .clientTop hack to using getComputedStyle() to stop the transition (apparently a style flush isn't enough to do it).

Thanks for reporting! Looking into it.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Potential patch cooking on try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=10a8ea0c0cdbcb21f1e37fea0d32c6921facdbe9

Comment 8

[Mike Conley (:mconley) (:⚙️)]

These builds fix the problem for me. Mayank and/or Alice0775 White, can you confirm it fixes it for you too?

Linux 64: https://queue.taskcluster.net/v1/task/MAsUNoayRrO4gn-IF6QkQw/runs/0/artifacts/public/build/target.tar.bz2
MacOS: https://queue.taskcluster.net/v1/task/IGYtdPB3Ss2bmnuV_g81-Q/runs/0/artifacts/public/build/target.dmg
Win 32: https://queue.taskcluster.net/v1/task/LaBEkY1sRNuxEejr2hjJKA/runs/0/artifacts/public/build/target.zip
Win 64: https://queue.taskcluster.net/v1/task/AfHVDS5LT5iEBmjveeiwvw/runs/0/artifacts/public/build/target.zip

Comment 9

[Alice0775 White]

I confirmed that the try build(Win64 and Linux) fixed the problem.

Comment 10

[Mayank Bansal]

wont be able to test the try builds. happy to test when this lands in nightly.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

ni?ing myself to get this cleaned up and posted for review now that I'm back from PTO.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1477461 - Make sure tab locking freezes tab width animations until after the next flush. r?dao

Before, we were disabling the transitions, forcing a style flush, and then immediately re-enabling
the transitions for the next flush.

Now, we disable the transitions, wait until the next flush completes naturally, and then
puts the transitions back during the next requestAnimationFrame. This lets us avoid
the sync style flush, and also gets us the tab size locking behaviour.

MozReview-Commit-ID: BU7AvBrhNxO

Comment 13

[Dão Gottwald [:dao]]

I wonder if we could improve this and related code with the Web Animations API...

Comment 14

[Dão Gottwald [:dao]]

Comment on attachment 8998537 [details]
Bug 1477461 - Make sure tab locking freezes tab width animations until after the next flush. r?dao

Dão Gottwald [::dao] has approved the revision.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/152ac3a5a10c
Make sure tab locking freezes tab width animations until after the next flush. r=dao

Comment 16

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/152ac3a5a10c

Comment 17

[Mayank Bansal]

confirmed this is fixed as of https://hg.mozilla.org/mozilla-central/rev/d999fb858fb2c007c5be4af72bce419c63c69b8e

Comment 18

[Mike Conley (:mconley) (:⚙️)]

Thanks!

Comment 19

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello all ,

I have reproduced the issue mentioned in Description using an affected 63.0a1 build from 2018-07-21.

This issue is verified fixed using the latest Firefox 63.0b8 and Nightly 64.0a1 on Windows 10 64bit, macOS 10.13.6 and Ubuntu 16.04.