Status

()

P2
normal
VERIFIED FIXED
a year ago
10 months ago

People

(Reporter: ahal, Assigned: ttaubert)

Tracking

(Depends on: 1 bug, {regression})

unspecified
Firefox 59
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox57 wontfix, firefox58+ verified, firefox59 verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
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.
(Reporter)

Comment 1

a year ago
Forgot to mention, this was before updating to todays nightly and I have stylo enabled.
Keywords: steps-wanted
OS: Linux → All
Hardware: x86_64 → All
Duplicate of this bug: 1399943
See Also: → bug 1381964
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?
Flags: needinfo?(dao+bmo)
I've never seen this myself and we have no steps to reproduce.
Flags: needinfo?(dao+bmo)
(Reporter)

Comment 5

a year ago
Fwiw, I haven't seen this since either.
See Also: → bug 1398142
(Reporter)

Comment 6

a year ago
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.
(Reporter)

Comment 7

a year ago
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.
Duplicate of this bug: 1407145
See Also: → bug 1406370
Keywords: regressionwindow-wanted
Priority: -- → P2
Duplicate of this bug: 1406370
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.
status-firefox58: --- → affected
Keywords: regression
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.
(Reporter)

Updated

a year ago
status-firefox57: --- → affected
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.
(Assignee)

Comment 16

a year ago
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
(Assignee)

Comment 17

a year ago
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.
(Assignee)

Comment 18

a year ago
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.
(Assignee)

Comment 19

a year ago
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.
(Assignee)

Comment 20

a year ago
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

Comment 21

a year ago
Pushed by ttaubert@mozilla.com:
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)

Updated

a year ago
Assignee: nobody → ttaubert
Status: NEW → ASSIGNED
Thanks Tim.

We'll want to uplift this to Beta.
Blocks: 1355507
status-firefox57: affected → wontfix
Keywords: regressionwindow-wanted, steps-wanted
tracking-firefox58: --- → ?
status-firefox59: --- → affected
tracking-firefox58: ? → +

Comment 23

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e9227aaffbe7
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox59: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
Flags: qe-verify+
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+

Comment 26

a year ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/33e95d96edd2
status-firefox58: affected → fixed
status-firefox-esr52: --- → unaffected
See Also: → bug 1421321
Duplicate of this bug: 1421909
This is VERIFIED FIXED in 58 beta 12 and the latest Nightly. Can not reproduce anymore. Marking it as fixed.
Status: RESOLVED → VERIFIED
status-firefox58: fixed → verified
status-firefox59: fixed → verified
Flags: qe-verify+

Comment 29

11 months ago
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+

Updated

10 months ago
Duplicate of this bug: 1424319

Updated

10 months ago
Depends on: 1427163
You need to log in before you can comment on or make changes to this bug.