Closed Bug 1576770 Opened 5 years ago Closed 3 years ago

Can't grab scrollbar to scroll on Tweetdeck with WR enabled

Categories

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

Unspecified
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1719913
92 Branch
Tracking Status
firefox68 --- affected

People

(Reporter: yoasif, Unassigned)

References

(Depends on 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.

Curious if you can reproduce this?

Flags: needinfo?(a.beingessner)

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.

Flags: needinfo?(a.beingessner)

(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!

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.

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.

Blocks: wr-71
Priority: -- → P3
Version: 68 Branch → Trunk
Flags: needinfo?(yoasif)

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.

Flags: needinfo?(yoasif) → needinfo?(pristineaccountant)

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!

Flags: needinfo?(pristineaccountant)

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?

Flags: needinfo?(a.beingessner)

Nope, if you can get a SingleFile that demonstrates the problem, that's all we should need.

Flags: needinfo?(a.beingessner)

Any luck reproducing?

Flags: needinfo?(yoasif)

Redirecting NI.

Flags: needinfo?(yoasif) → needinfo?(pristineaccountant)

FYI - I am also having this issue. One day, there will be dozens of us!

(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

Flags: needinfo?(amantgeorge)
Blocks: wr-72
No longer blocks: wr-71

pristineaccountant - have you been able to reproduce this on your 'throwaway' account?

(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?

Flags: needinfo?(amantgeorge)

Go to about:support, then click Copy text to clipboard, then click on "Attach new file" in this page and paste it. Thanks!

See comment 17 for instructions on adding your about:support info

Flags: needinfo?(amantgeorge)
Blocks: wr-wild
No longer blocks: wr-72
Attached file about:support
Hello, i have the same problem with tweetdeck but only with lists or searches i add as columns. about:support below.
Attached file about:support

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, [...]

Attached file about:support

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.

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.)

Attachment #9202542 - Attachment description: FF support WR enabled.txt → about:support (WR enabled)
Attachment #9202543 - Attachment description: FF support WR disabled.txt → about:support (WR disabled)

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 :/

See Also: → 1712040
Blocks: 1712040
See Also: → 1719913

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.

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.)

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.

Depends on: 1722429

(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 to 0 in about: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.

@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!

Flags: needinfo?(pristineaccountant)
Flags: needinfo?(amantgeorge)

(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)

Flags: needinfo?(pristineaccountant)
Flags: needinfo?(joemcken64)
Flags: needinfo?(hjalte)
Flags: needinfo?(gina)
Flags: needinfo?(eric.debra)
Flags: needinfo?(amantgeorge)

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!

Flags: needinfo?(gina)

Wonderful, thank you for confirming!

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(pristineaccountant)
Flags: needinfo?(joemcken64)
Flags: needinfo?(hjalte)
Flags: needinfo?(eric.debra)
Flags: needinfo?(amantgeorge)
Resolution: --- → DUPLICATE
Target Milestone: --- → 92 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: