Can't grab scrollbar to scroll on Tweetdeck with WR enabled
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | affected |
People
(Reporter: yoasif, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(7 files)
Reported on reddit: https://www.reddit.com/r/firefox/comments/csnedm/tweetdeck_scrollbar/
User says:
On tweetdeck, I can't grab a scrollbar with my mouse to scroll. mouse wheel or touch screen scrolling works fine, along with clicking above and below the current bar position to scroll, but not actually grabbing the bar and dragging up and down.
User confirmed that disabling WR resolves the issue.
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
I couldn't with some quick testing. I'm going to contact the user on reddit to get some details. In particular interested if this still happens on nightly and/or beta.
Comment 4•5 years ago
|
||
(In reply to Alexis Beingessner [:Gankra] from comment #3)
I couldn't with some quick testing. I'm going to contact the user on reddit to get some details. In particular interested if this still happens on nightly and/or beta.
Hey all, so I'm the owner of the original reddit thread. A few questions were asked of me, which I'll answer here!
Hey there, I work on Webrender and am making sure we check this out, since it's pretty serious. If you have a bugzilla account, would definitely appreciate getting the reply to the following questions over in the bug just so everything important is in one place. :)
Hi! :D
You're seeing this on the stable release of firefox, would you be willing to test out nightly (and possibly also beta if nightly does work), to see if we've incidentally fixed this?
I tested this on beta and nightly, same results on both. Same 'testing' profile though, I didn't create a fresh profile for nightly. UNused in every other way, no add-ons, etc.
Do you have an interesting monitor setup? Multiple monitors? Are you running any of your monitors at different "scales" to compensate for hidpi?
So I was able to reproduce this on a second computer on my main, synced profile. Nothing special about either monitor setup. Both are single monitor setups, one is 1080, the other is 1440.
Is it literally just tweetdeck that has this problem? Nothing else?
I've had no problems elsewhere, just tweetdeck so far!
Comment 5•5 years ago
|
||
Sorry, tacking on to my previous comment, I've discovered something interesting.
On my main, synced profile and the test profile I've created I logged out of tweetdeck and logged back in another account. Scrolling is working fine.
I re-login to the 'affected' account, and scrolling stops working again.
It appears something specific to my tweetdeck account is having an ill effect.
Comment 6•5 years ago
|
||
Well this is just an extremely evil bug then, huh.
Kind of a reach, but would you be willing to use the SingleFile extension to try to save the version of tweetdeck you're seeing: https://addons.mozilla.org/en-CA/firefox/addon/single-file/
It would be very reasonable to refuse to do this if you're worried about the private information of your twitter account being leaked.
Also there's no guarantees that it will actually properly reproduce once SingleFile is done with it. But otherwise I don't know how we can possibly hope to fix this if tweetdeck is giving you a special evil page.
Updated•5 years ago
|
Reporter | ||
Comment 7•5 years ago
|
||
Redirecting NI.
Well this is just an extremely evil bug then, huh.
Kind of a reach, but would you be willing to use the SingleFile extension to try to save the version of tweetdeck you're seeing: https://addons.mozilla.org/en-CA/firefox/addon/single-file/
It would be very reasonable to refuse to do this if you're worried about the private information of your twitter account being leaked.
Also there's no guarantees that it will actually properly reproduce once SingleFile is done with it. But otherwise I don't know how we can possibly hope to fix this if tweetdeck is giving you a special evil page.
Comment 8•5 years ago
|
||
Apologies for the delayed reply! Indeed this bug does seem very narrow in scope.
I totally understand how grabbing my specific version of tweetdeck would be of great assistance, Unfortunately I'm indeed unable to share that information as is, not because of my own account (which I don't really care about, it's all public stuff anyways!) but because of some corporate and business accounts that I manage that includes private information contained within locked accounts and, of course, private DMs.
At present I've just been using the unaffected account with no problems so far. I've attached the other accounts I manage to that unaffected account, to no detriment. I'll keep tabs on this new setup I have to see if it will eventually suffer from the same issue. When I have a little more free time, I can trim the privacy fat off of the affected account, and see if the account is still afflicted, in which case I can share the Singlefile without sharing compromising data. If that sounds good!
Otherwise I have to agree, I'm not sure how to track down this oddly specific bug. Thank you though for your help!
Comment 9•5 years ago
|
||
So unfortunately my workaround using another account has failed, the bug has reappeared. However I noticed something strange as the timing didn't seem quite right (why would it appear suddenly two days later?) and when I did a little bit of deeper digging, I discovered something new!
If I open the new tweet panel (top left on tweetdeck) - scrolling works again, consistently as far as I can tell, until I reload the page. I don't have to keep the panel open either. So after every reload of tweetdeck, I just quickly open and close the new tweet panel. This 'workaround' occurs on both the latest stable and nightly, across mutliple PCs using different profiles. Easily reproduced on my end.
It was a little harder to figure this one out because I don't often post new tweets from my desktop, (Usually easier via phone!) mostly just inline replies. (which doesn't involve the new tweet panel unless the pop-out option is specifically activated.)
I'm going to try and make a throwaway twitter account to see if I can reproduce the bug in that (Hopefully it doesn't take two days?) and then post the SingleFile here. With this new discovery, is there anything else I can do to lend a hand in squashing this oddity?
Comment 10•5 years ago
|
||
Nope, if you can get a SingleFile that demonstrates the problem, that's all we should need.
Reporter | ||
Comment 12•5 years ago
|
||
Redirecting NI.
Comment 14•5 years ago
|
||
(In reply to amantgeorge from comment #13)
FYI - I am also having this issue. One day, there will be dozens of us!
Can you please attach your about:support as a text file? This will help us track down how to reproduce
Updated•5 years ago
|
Comment 15•5 years ago
|
||
pristineaccountant - have you been able to reproduce this on your 'throwaway' account?
Comment 16•5 years ago
|
||
(In reply to Jessie [:jbonisteel] plz needinfo from comment #14)
(In reply to amantgeorge from comment #13)
FYI - I am also having this issue. One day, there will be dozens of us!
Can you please attach your about:support as a text file? This will help us track down how to reproduce
Hey - happy to, but I'm a new user, how do I attach the file?
Comment 17•5 years ago
|
||
Go to about:support
, then click Copy text to clipboard
, then click on "Attach new file" in this page and paste it. Thanks!
Comment 18•5 years ago
|
||
See comment 17 for instructions on adding your about:support info
Updated•5 years ago
|
Comment 19•5 years ago
|
||
Hello, i have the same problem with tweetdeck but only with lists or searches i add as columns. about:support below.
Comment 20•5 years ago
|
||
Same issue for a while now. Here's the about:support
output (sorry for the french there).
Also thanks to pristineaccountant for the temp fix in comment #9:
If I open the new tweet panel (top left on tweetdeck) - scrolling works again, [...]
Comment 21•4 years ago
|
||
I can reproduce this. Specifically, the trigger seems to be the appearance of the horizontal scrollbar at the bottom of the page (i.e. the window is too narrow to show all the columns fully). Once this has appeared, columns other than the leftmost one can no longer be scrolled by dragging their scrollbars. This persists even if the window is made larger so that the horizontal scrollbar disappears. Sometimes the leftmost column's scrollbar and horizontal scrollbar also stop working, possibly when the window has been made especially narrow. Opening the new tweet panel does somehow fix things.
Seems to happen on nightly and release channels, only with Webrender enabled.
Comment 22•4 years ago
|
||
I have the same issue. I noticed it when I first updated to v83 a few days ago, and just now found itβs due to WebRender. Iβve temporarily resolved the issue by disabling WR.
Also, Iβll add that in addition to locking all but the left-most scrollbars, WR also messes up the appearance of fonts on TweetDeck, making them look kinda thinner and more jagged, as if it took away their anti-aliasing or something. (Iβm not an expert so I canβt give more detail than that. It just made the fonts ugly.)
(This is my first time using Bugzilla and attaching a file, apologies if I did something incorrectly.)
Comment 23•4 years ago
|
||
Comment 24•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 25•4 years ago
|
||
Chiming in with another "seeing this too", workaround of opening the compose sidebar works as well. Happy to assist however I can, but sadly cannot share a singlefile for privacy reasons.
And sorry for the busy edits up there, it's been a LONG time since I used bugzilla, plus I'm not really used to file upload and commenting being different, hence the multipost :/
Updated•3 years ago
|
Updated•3 years ago
|
Comment 26•3 years ago
|
||
I recently wrote a fix for a similar issue, bug 1719913, also specific to WebRender but with milder symptoms: dragging the scrollbar works on all columns, but there is a jump in scroll position (and scrollbar position) when you start dragging.
Playing around with it a bit further, I discovered that setting slider.snapMultiplier
to 6
in about:config
worsens the symptoms (without the fix) such that, now, the scrollbars of the second and subsequent columns cannot be dragged at all (i.e. the symptoms described in this bug). My fix for bug 1719913 fixes this scenario as well.
Note that the default value of slider.snapMultiplier
is 6
on Windows, and 0
on other platforms, so this may explain why some people were unable to reproduce this (if they were testing on Mac or Linux).
Based on this, I strongly suspect that this is a duplicate of bug 1719913, and will be fixed by the patches in that bug. We should confirm this once the patches hit Nightly (which hasn't happened yet), by asking the reporter (or someone else who chimed in here in this bug) to test with the latest Nightly.
Comment 27•3 years ago
|
||
Some follow-up notes, in case you're wondering what slider.snapMultiplier
is, and why it affects this bug:
slider.snapMultiplier
is a setting that controls a feature of scrollbar dragging whereby, if the mouse gets too far away from the scrollbar (in the direction opposite of scrolling, e.g. horizontally for a vertical scrollbar), then the scrollbar snaps back to its position at the start of the drag. A value of 0
for this setting disables the feature, whereas a positive value controls the size of zone (denominated in units of scrollbar width) outside of which the snapping occurs (so 6
, the default value on Windows, means the snapping occurs when the mouse gets further than 6 times the scrollbar width away from the scrollbar).
The cause of bug 1719913 was an incorrect calculation of the mouse position relative to the scrollbar thumb. The value was incorrect in both the horizontal and vertical directions. Being wrong in the vertical direction caused the "jump" observed in bug 1719913. Being wrong in the horizontal direction had no effect when the snapping feature is disabled; when it's enabled, it has the potential of making us believe incorrectly that the mouse is inside the snap zone, thereby causing the scrollbar thumb to be stuck in the snapped position.
The magnitude by which the horizontal mouse position was off was proportional to the horizontal position of the element being scrolled relative to the page. This is why the bug didn't affect the first column, but did affect subsequent columns. (However, even for the first column, you can see the snap zone is incorrect - on the right side, we snap sooner than we should, and on the left side, later than we should. Additionally, for the second and subsequent columns, you can get out of the snap zone and drag normally if you move the mouse way to the left during dragging.)
Comment 28•3 years ago
|
||
More immediately relevant to users experiencing this bug: if you'd like a workaround while waiting for the fix of bug 1719913 to reach Nightly or Release, as an alternative to disabling WebRender, you can set slider.snapMultiplier
to 0
in about:config
, and then restart the browser.
Comment 29•3 years ago
|
||
(In reply to Botond Ballo [:botond] [away until Aug 13] from comment #28)
More immediately relevant to users experiencing this bug: if you'd like a workaround while waiting for the fix of bug 1719913 to reach Nightly or Release, as an alternative to disabling WebRender, you can set
slider.snapMultiplier
to0
inabout:config
, and then restart the browser.
Just did, and indeed having it at 0 instead of the default 6, you at least from scratch can scroll now on Tweetdeck. But now you've the bug 1719913 (aka the jump down of the scrollbar with your cursor above scrollbar while scrolling if you gripped in the top part). I'll stick to the current known easy fix being to open/close the new tweet UI in Tweetdeck until a proper fix is released.
Thanks for the efforts to solve all this o/. Hopefully we'll see your fix soon in the release version.
Comment 30•3 years ago
|
||
@pristineaccountant, or anyone else who reported experiencing this issue: could you please try a recent Firefox Nightly (which will include the fix for bug 1719913), and verify that the issue has been resolved? Thanks!
Updated•3 years ago
|
Comment 31•3 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #30)
@pristineaccountant, or anyone else who reported experiencing this issue: could you please try a recent Firefox Nightly (which will include the fix for bug 1719913), and verify that the issue has been resolved? Thanks!
(needinfoing some of the people who reported experiencing this issue)
Comment 32•3 years ago
|
||
I can no longer reproduce the issue under Firefox Nightly (just installed 93.0a1 (2021-08-17) (64-bit) and attempted reproduction, unsuccessfully). Good job, thank you very much!
Comment 33•3 years ago
|
||
Wonderful, thank you for confirming!
Updated•3 years ago
|
Description
•