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)
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.
Updated•7 years ago
|
Component: Untriaged → Graphics: WebRender
Keywords: nightly-community
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Version: 61 Branch → Trunk
Updated•7 years ago
|
Blocks: 1191971
status-firefox59:
--- → unaffected
status-firefox60:
--- → unaffected
status-firefox61:
--- → disabled
status-firefox-esr52:
--- → unaffected
status-firefox-esr60:
--- → unaffected
Keywords: regression
Updated•7 years ago
|
Blocks: stage-wr-trains
Priority: -- → P2
Comment 2•6 years ago
|
||
(In reply to ssj2kite from comment #0)
Can you still reproduce this?
Flags: needinfo?(ssj2kite)
(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)
Comment 4•6 years ago
|
||
I tried to reproduce the issue, but I could not reproduce the problem with nightly 20180516220130 nor with latest nightly on 2 Win10 PCs :(
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.
Comment 7•6 years ago
|
||
(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.
Updated•6 years ago
|
Comment 9•6 years ago
|
||
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.
Description
•