Closed Bug 1396833 Opened 5 years ago Closed 5 years ago
Tabs can overlap
https://i.imgur.com/QCI1EIt.png Restarting the browser fixed the issue. Note the overlapping tabs on the left and the gap on the right (presumably the same width as the overlapped portion). The close button on that newtab page is also un-clickable (though ctrl-w works). Otherwise switching, closing and other tab operations seem to work normally. Wish I could provide more details, but I can't reproduce and have no idea how I got into this state.
Forgot to mention, this was before updating to todays nightly and I have stylo enabled.
OS: Linux → All
Hardware: x86_64 → All
Dao -- what do you want to do here? Is there something we can investigate (especially since there seem to be a few related bugs), or is this non-reproducible / inactionable?
I've never seen this myself and we have no steps to reproduce.
Fwiw, I haven't seen this since either.
I hit this again. It happened when tabs overflowed the tab bar, and persisted even after closing + re-opening them. Restarting Firefox fixed the issue again.
Oh yeah, and any tabs after the overlapping tabs can't be closed by clicking the 'x'. My theory is that Firefox still thinks they are in their normal positions but they just aren't being drawn properly.
As per bug 1406370, I've seen this occasionally. I've also seen slightly more recently that the chrome UI part of FF seems to lock up completely and won't re-render. Restarting fixes it. There's nothing mentioned on the browser console either.
Looking through all the dupes/see alsos, seems like this bug is tricky to reliably hit. :|
(In reply to Andrew Halberstadt [:ahal] from comment #7) > Oh yeah, and any tabs after the overlapping tabs can't be closed by clicking > the 'x'. My theory is that Firefox still thinks they are in their normal > positions but they just aren't being drawn properly. When I hit this, the X doesn't work for the current active tab (even if I switch to one that isn't moved around). The X *does* work for closing background tab, even if they are shifted around in the wrong position.
Report from the support site: https://support.mozilla.org/en-US/questions/1184823
Another observation I had was that the mouse-over effect wasn't working for the current tab. I believe the rendering is fine and the js/xbl for the tabbar is wrong. It seems like close state was was toggled due to some animation/drag/overflow and we lost an event and never undid the state. Unfortunately the browser debugger refused to start so I could not look at any data.
My wife has hit this (on macOS) a couple of times since upgrading. I got a Browser Toolbox Inspector screenshot of it at https://www.dropbox.com/s/mlrxyvb9y9wp931/TabOddities.png?dl=0 which might be of some help? (At least it tells us that the first non-pinned tab has a wildly incorrect `translate: transformX` value.) If there are other things you'd like me to poke into the next time it happens, I'm more than happy to help.
I'm currently able to reliably reproduce this. I need a certain number of tabs, open a new one and drag&drop it quickly to the very right, before it's loaded. In the console I see this: ASSERT: Giving up waiting for the tab closing animation to finish (bug 608589) NS_ASSERT resource://gre/modules/debug.js:53:3 removeTab/< chrome://browser/content/tabbrowser.xml:3157:17
After dropping the tab, it's still "floating", the tabbar still has [movingtab=true]. I assume that somehow _finishAnimateTabMove() isn't called when it should be.
Removing the "floating" tab is what breaks the UI then, not surprisingly. I can see that <handler event="drop"> is called and we enter the following branch: https://searchfox.org/mozilla-central/rev/c633ffa4c4611f202ca11270dcddb7b29edddff8/browser/base/content/tabbrowser.xml#7601 That transition probably doesn't end. I'll check the translateX values to see what's up here.
oldTranslateX=1259.1000061035156 and newTranslateX=1259.0999450683594. I'm not sure what the rules around sub-pixel transforms are... but it seems like in this case that's too close together and we just do nothing.
Submitted a patch that fixes the issue for me. I found only mconley on Phabricator, but I'll take reviews from any other browser peer ;) https://phabricator.services.mozilla.com/D265
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/e9227aaffbe7 Fix tab drag&drop not finishing due to CSS transform not kicking in r=mconley
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Thanks Tim. We'll want to uplift this to Beta.
Comment on attachment 8930159 [details] Bug 1396833 - Fix tab drag&drop not finishing due to CSS transform not kicking in Approval Request Comment [Feature/Bug causing the regression]: bug 1355507 [User impact if declined]: see comment 0 [Is this code covered by automated tests?]: no [Has the fix been verified in Nightly?]: not yet [Needs manual test from QE? If yes, steps to reproduce]: see comment 16, although this probably isn't reproducible everywhere. Might be DPI dependent. [List of other uplifts needed for the feature/fix]: / [Is the change risky?]: no [Why is the change risky/not risky?]: trivial fix [String changes made/needed]: /
Attachment #8930159 - Flags: approval-mozilla-beta?
Comment on attachment 8930159 [details] Bug 1396833 - Fix tab drag&drop not finishing due to CSS transform not kicking in Fix an overlapped tabs issue. Beta58+.
Attachment #8930159 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
This is VERIFIED FIXED in 58 beta 12 and the latest Nightly. Can not reproduce anymore. Marking it as fixed.
Comment on attachment 8930159 [details] Bug 1396833 - Fix tab drag&drop not finishing due to CSS transform not kicking in Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos has approved the revision. https://phabricator.services.mozilla.com/D265#6517
Attachment #8930159 - Flags: review+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.