Closed Bug 1455518 Opened 7 years ago Closed 6 years ago

Tabs resize when middle-click closing with webrender

Categories

(Core :: Graphics: WebRender, defect, P2)

x86_64
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 --- disabled

People

(Reporter: ssj2kite, Unassigned)

References

Details

(Keywords: nightly-community, regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180419224145 Steps to reproduce: Nightly 20180419224145, win10, clean profile, set gfx.webrender.all to true and restart. Then go to any website (ex. https://www.mozilla.org/en-US/) and open a bunch of tabs (ex. middle clicking the "Firefox" link at the top say 8 times), then select the 2nd tab (the first https://www.mozilla.org/en-US/firefox/ that was opened). Now hover over the active tab and middle click to close it (may take a few closes). Actual results: The group of tabs resizes itself, changing your mouse position. Expected results: The mouse should stay stationary as to not suddenly switch the tab you're hovering over. Most the times I run into this is when I'm middle click closing an active tab with my cursor near the favicon and the tabs adjust so that the next middle click would close the tab to the left of what I just closed instead of new active tab that was to the right of it (that took the closed tabs place). From some further testing, trying this by closing several newtabs with the Firefox Home (Default) setting selected won't trigger this bug, but webpages and blank page newtabs will. Mozregression pointed to bug #1191971, and setting gfx.webrender.dcomp-win.enabled to false did fix the issue. There's still the occasional tab resize when spam middle clicking that shows up with or without webrender+dcomp, but I think that's caused by mouse movement and unrelated to this bug.
> The mouse should stay stationary as to not suddenly switch the tab you're > hovering over. *The tabs should stay stationary as to not suddenly switch where your mouse is relative to your tabs, potentially switching the tab you're hovering over.
Component: Untriaged → Graphics: WebRender
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Version: 61 Branch → Trunk
(In reply to ssj2kite from comment #0) Can you still reproduce this?
Flags: needinfo?(ssj2kite)
Attached video tabs improperly resizing webm (deleted) —
(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #2) > (In reply to ssj2kite from comment #0) > Can you still reproduce this? Yes, on nightly 20180516220130 with my daily use profile, or with a clean profile (with gfx.webrender.all to true) launched from mozregression. I've attached a webm of it happening on the clean 20180516220130 profile.
Flags: needinfo?(ssj2kite)
I tried to reproduce the issue, but I could not reproduce the problem with nightly 20180516220130 nor with latest nightly on 2 Win10 PCs :(
Attached video tabs improperly resizing still 6-29-18 (deleted) —
Added another webm, showing exactly what I did to reproduce, using nightly build 20180628220051 and Mozregression-gui 0.9.22 on Windows 10 Pro version 1803 (build 17134.112). I've tested this with using my actual middle mouse button and binding middle click to a key (as to eliminate mouse jitter), happens with both. If it's somehow hardware related, I'm on a 4770k@4.2GHz, GTX 770 (driver 391.24), 2x8GB DDR3 2400 RAM, using a Razer Naga Hex V2 mouse (running Razer Synapse 2.21). Unfortunately I don't have any spare hardware to check if this issue happens under different circumstances.
Testing this again today, this seems to have been fixed by bug #1472230. I still don't know why it was only happening with webrender enabled to begin with though.
Depends on: 1472230
(In reply to ssj2kite from comment #6) > Testing this again today, this seems to have been fixed by bug #1472230. I > still don't know why it was only happening with webrender enabled to begin > with though. Uh... yeah, this doesn't make a lot of sense to me. Are you sure it's that bug, not something else that landed between the same set of nightlies? :-(
(In reply to :Gijs (he/him) from comment #7) > (In reply to ssj2kite from comment #6) > > Testing this again today, this seems to have been fixed by bug #1472230. I > > still don't know why it was only happening with webrender enabled to begin > > with though. > > Uh... yeah, this doesn't make a lot of sense to me. Are you sure it's that > bug, not something else that landed between the same set of nightlies? :-( Mozregression pointed towards that bug, bisecting from bad 20180628220051 good 20180703220118 searching for bug fixes. I can rerun it and post the results here if you'd like.
Blocks: 1472230
No longer depends on: 1472230
I agree it doesn't make a lot of sense, but if this is no longer happening, we can close this bug. Please reopen if you still see it.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: