Closed Bug 1477461 Opened Last year Closed Last year
Closing a tab moves all the tabs while the mouse is still on the tab-bar
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
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:
Are you able to reproduce this if you close the tabs with the close icon (the X)?
(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.
OS: Unspecified → All
(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.)
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.
Assignee: nobody → mconley
Status: NEW → ASSIGNED
See Also: → 649247
Potential patch cooking on try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=10a8ea0c0cdbcb21f1e37fea0d32c6921facdbe9
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
I confirmed that the try build(Win64 and Linux) fixed the problem.
wont be able to test the try builds. happy to test when this lands in nightly.
ni?ing myself to get this cleaned up and posted for review now that I'm back from PTO.
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
I wonder if we could improve this and related code with the Web Animations API...
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.
Attachment #8998537 - Flags: review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/152ac3a5a10c Make sure tab locking freezes tab width animations until after the next flush. r=dao
confirmed this is fixed as of https://hg.mozilla.org/mozilla-central/rev/d999fb858fb2c007c5be4af72bce419c63c69b8e
Status: RESOLVED → VERIFIED
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.
You need to log in before you can comment on or make changes to this bug.