Repository navigation
Threading UI: Cannot scroll back to or access tweets that the current tweet is a reply to #164
Description
Describe the bug
In Cawbird 1.1.0, viewing a single tweet that is a reply to some other tweet(s) shows me replies to that tweet (below the tweet), but doesn't show the tweets that the current tweet is a reply to. In 1.0.x these appeared below the single tweet; my understanding is that in the new threading UI, these are supposed to show above the tweet and have to be scrolled into view. However, I cannot scroll them into view in any way. Either no scroll bars appear or the scroll bars stop at the tweet I'm viewing, my mouse wheel will not scroll up past the single tweet, and cursor keys on the keyboard don't produce any effect.
This happens both with the official Fedora Linux RPM for Fedora 31 ('cawbird-1.1.0-2.fc31.x86_64', from the Fedora updates repository) and with a hand-built RPM built from git head ('v1.1.0-2-1-g1dbaab99'). Viewing a single tweet that's a reply doesn't print any warnings or errors on standard output/standard error. I am using a non-standard desktop environment (fvwm as a window manager and no particular 'desktop' environment), but I can't see why this would affect in-app behavior.
Activity
IBBoard commentedon Jun 12, 2020
Can you give an example tweet? It all works fine for me (even for long threads).
The scrollbars won't show anything above by default, because there kind of isn't anything above as far as the app is concerned. The way Baedert built it is some weird kind of zero height container widget, and the "scroll up" even gets caught and turned in to "expand the box". But it's still just the same widget as when replies were above the tweet, just with different contents.
If you're building custom RPMs then I'll hack together a quick patch to test.
siebenmann commentedon Jun 12, 2020
Anything that's a reply does it for me. One random example (a current one) is: https://twitter.com/tef_ebooks/status/1271420594849026053
I can build with a patch without problems, and I can put a screenshot of what Cawbird 1.1.0 looks like for me while reading a tweet somewhere if you want to see it.
IBBoard commentedon Jun 12, 2020
Easy enough patch:
Whenever you scroll you should see "Scrolling...". When you hit the top and it should expand then you should also see some details. You should also see some details about it loading the thread, e.g.:
If you don't see the "loaded replied-to" then it isn't loading the thread for some reason. If you see "Scrolling" but not the delta etc then we're missing something in the conditions.
You may need to run it as
G_MESSAGES_DEBUG=cawbird cawbirdto see the debug (depending on whether your RPM builds as a debug build or not).siebenmann commentedon Jun 12, 2020
I see the "loaded replied-to" messages, but not the delta and other information. Some additional debugging stuff says that the scroll stuff knows that this is a reply but that it always seems to see a delta of 0 when I try to scroll up:
IBBoard commentedon Jun 12, 2020
If the scroll info is zero then that would definitely cause problems, because we don't know that we're scrolling up!
I'll try to look in to it over the weekend and see if that's the proper way to detect scroll direction. If it is then it suggests fvwm might be interfering/not sending the right signals (although I'd assumed scrolling of widgets was a GTK thing, but maybe GTK isn't getting the right signals).
One thought: If you keep the extra debugging in (outside the IF) and find something with lots of replies so that you've got a scrollbar, do you see negative values when you scroll down and then back up (i.e. you're not at the top)? I'm wondering whether something is trying to be "clever" and deciding that there's no 'up' to scroll to and so it zeroes the value.
siebenmann commentedon Jun 12, 2020
Scrolling this: https://twitter.com/ZhugeEX/status/1271519047985836033
I see consistent reports of
(cawbird:3340065): cawbird-DEBUG: 15:28:26.162: TweetInfoPage.vala:164: Scroll info: 0.000000; vadjustment 1245.731580, container size: 0with varying vadjustment values but always 0 for the others. The vadjustment goes up when I scroll down, and down when I scroll up,IBBoard commentedon Jun 12, 2020
Huh. Clearly we can't trust that value then. There's a simple work-around, but I'll see if I can find a proper fix.
Presumably this means that you've never been able to scroll up to see the replies, but just never noticed!
siebenmann commentedon Jun 12, 2020
Oh, I just learned something new about Cawbird. If the old interface also showed replies to the tweet on top, yes, I've never been able to scroll up to see them and in fact I thought Cawbird (and before it Corebird) couldn't show them. I always went to the website to see replies. (Cawbird and Corebird would put up the marker that there were replies, which I used as 'go to the website' cue.)
(Before now I assumed this was a limitation of either the Twitter API or Cawbird's willingness to do weird things to extract the replies from the Twitter API.)
IBBoard commentedon Jun 13, 2020
No, they were there. That coloured line was Baedert's way of saying "there's stuff to scroll up to".
I may have found a clue, though!
Does this fix it? And does it scroll okay? If it scrolls too much/too little, can you add a debug line to show the
evt_delta_y? I might just have to go for a fixed multiplier.siebenmann commentedon Jun 13, 2020
Unfortunately this still doesn't scroll, and reports that the new evt_delta_y is 0.
IBBoard commentedon Jun 13, 2020
That's not right! That's not what the docs say. Although the patch might still fix scrolling issues for other people who do have smooth-scroll (or normal scroll? I'm starting to lose track of what the documentation is telling me!).
Back to the drawing board.
IBBoard commentedon Jun 13, 2020
I've installed fvwm2-2.6.9 with this patch:
And it seemed to work okay. It was logging "GDK_SCROLL" events, failed direction, but valid deltas.
What else are you running other than fvwm? Do you have any special settings?
siebenmann commentedon Jun 13, 2020
What I see reported from your patch is:
This is reported for all scroll events, both scrolling up and down in replies to the single tweet I'm looking at and trying to scroll up to see tweets it's a reply to.
I can't think of anything special that I'm doing besides using fvwm, except that I'm doing this with a physical mouse (and scrollwheel) instead of a laptop touchpad. For the scrollwheel,
xevreports:(Button 4 is up, button 5 is down.)
IBBoard commentedon Jun 14, 2020
Okay, something is really odd if it thinks it got a valid direction (
successis true) but it always says "UP". I was always getting "UP" without that check, because it's then an undefined value, but with the check then it should be giving us the correct direction if it says it was successful.One thing I thought when trying to do the hackish work-around: What vadjust value do you see when you scroll up and you're at the top? Presumably it is still 0, because you get a scroll event but haven't gone off the top of the widget, but I wanted to check.
[Edit] Interestingly,
xevis giving me state 0x10 and 0x810/0x1010 rather than 0x0 and 0x800/0x1000. I don't know what that flag will be, but we can hopefully find out and see if that's relevant.siebenmann commentedon Jun 14, 2020
Sorry, I should have been clearer. The direction switches between up and down depending on which way I'm scrolling; I showed the messages for trying to scroll up at the top of a tweet that was a reply. The vadjustment value I see for trying to scroll at the top of a tweet is 0, and it looks like I only see that on scroll up events when I'm already at the top of the normal scroll area.
As for the state that
xevprints, I think that this is just what buttons and modifiers you had pressed at the time, per here. My 0x0 and 0x800/0x1000 are because I had no modifiers active. Based on the Mask values in X11/X.h, your values suggest that you have 'Mod2' active.18 remaining items
JayVii commentedon Aug 9, 2020
Sorry for the late reply, unfortunately, the patch not not be applied for some reason (I tried both ways suggested by you):
For the later, the rejects are:
Also tried to apply it to the version of 806ec4d15277e4a261ab71e0f7016d6d18722655, since that's the date you also commented that patch in here, but the outcome was the same. Am I missing something?
IBBoard commentedon Aug 10, 2020
Looks like the patch is based on 27f572e - I must have either had it in a branch and not released, or else I managed to change the date while rebasing the branch or something. Or it never actually applied cleanly.
This patch should work on the current master:
I suspect you'll see:
And then someone needs to find out why your platform is sending/setting neither direction nor delta.
JayVii commentedon Aug 11, 2020
Patch ran through fine and cawbird compiled without issues.
I can see nothing about deltas when running it.
Here is the output when I open some reply to another tweet:
And when i try to scroll (swipe up or down the screen), obviously with nothing happening:
Often times, when trying to scroll while some reply is open, there is no output at all. I think the message above appears if it highlights text of the tweet.
So it appears to not be able to even register the scroll attempt, is that right?
IBBoard commentedon Aug 12, 2020
Yeah. If you're not getting any messages at all then your device isn't registering an attempt to scroll. Nothing we can do if we don't even get the event!
Just trying to debug your platform - have you tried it on a tweet that does scroll (e.g. a tall one, or one with replies)? Maybe your platform doesn't generate scroll events when there's no scroll bar?
JayVii commentedon Aug 13, 2020
No output either... Maybe one could workaround the issue with keyboard shortcuts? The squeekboard supports arrow-keys, so maybe mapping the up and down arrows to scrolling could be an option to at least make it usable in some way
IBBoard commentedon Aug 13, 2020
What, no output at all? Even if you scroll down? Because that makes no sense! It shouldn't be able to scroll at all without a scroll event.
I've just checked and I'd have hoped that Page Up worked, but apparently it doesn't. We can't mess with up/down because that's used for keyboard navigation between widgets.
I still feel there should be a better way of doing this that doesn't rely on restricted height elements. But I don't know how to make GTK keep its position while adding more content above (populating up the thread).
JayVii commentedon Aug 13, 2020
No, it does not give any output when scrolling, unless new tweets have to be fetched.
EDIT: I may add, that scrolling in cawbird on the pinephone is a little bit fiddly anyways. It sometimes starts to jump around a lot... Could be another issue entirely and shall not be subject in this discussion.
Maybe scrolling up for the parent tweet is not the best option after all. There could be an additional Button next to each tweet (or link, like the currently implemented "Source" link for every tweet with opens it in your webbrowser), which when pressed opens the parent tweet as if one had opened that parent tweet from the timeline directly.
EDIT2: Screenshot from my Desktop, rather than the pinephone, because that was easier now and it does not really matter: The Link (or Button) I was referring to above could be implemented through the line "Antwortend auf" (Replying to) in that screenshot.
IBBoard commentedon Aug 14, 2020
It seems like either Pinephone is performing magic (scrolling without scrolling), Pinephone is broken (scrolling but somehow GTK isn't sending scroll events), or you're not running the patched version of the app (possible if there's still a legacy version somewhere).
Overriding the scrolling behaviour so that it expands the height of a widget to simulate scrolling up definitely isn't the best option. But that's what Baedert implemented in Corebird and I've not found a better option so it's what we're stuck with!
Adding a button would be possible, but may clutter the UI too much. We can't really linkify the "Replying to" line because that will get too confusing with having linkified the usernames as well (you're getting to small gaps between hitzones for clicking). Adding a button there would be clunky and ugly. And even adding an extra bit of text to link would add noise and look a bit forced (because it would likely be something like "Replying to @-blah and @-blahblah. View Parent Tweet." or something).
It also means it stops mirroring "scroll down to see reply thread". And it would be a much less fluid experience as you clicked up each tweet one-by-one. And it would result in more requests, because we'd then load the replies to the parent tweet.
JayVii commentedon Aug 16, 2020
Purism has their own gtk "patched to work with phones". The patches are also used in Mobian, the OS I am using on the pinephone. I am not entirely certain, whether this might actually be an issue with the patches used to be able to scroll with a touchscreen, rather than cawbird. And I am not entirely sure how to find out...
This is a valid concern, I am not sure either on how to approach this.
IBBoard commentedon Aug 16, 2020
If they've patched GTK then anything could be happening. They might be scrolling without generating scroll events, although I don't know why that behaviour would be all that different to scrolling with a touchpad or a tablet and pen.
Your best bet at this point is to talk to someone who knows Purism/Mobian and what they've done differently to see why Cawbird isn't getting scroll events. If it's a bug then they can fix it. If there's a different event to hook in to (and we can do it without breaking things on the desktop) then we can see about adding support for it.
Re #164: Handle smooth scroll events
Re #164: Fall back to scroll direction if no delta
JayVii commentedon Sep 10, 2020
FYI, scrolling still doesn't work on the Pinephone (and I haven't figured out the GTK thing yet either) BUT with 1.2.0 freshly built from git, scrolling up with the arrow keys from the software keyboard does work (it did not in 1.1.0, I just checked that). Not entirely sure why that is, but it just became very well usable through that.
IBBoard commentedon Sep 10, 2020
That would be because of #143, where I improved various accessibility things, including making keyboard navigation more consistent!
I had a brief thought after you posted this that maybe Pinephone wasn't sending scroll events because it was making the widget the maximum height of its content and then scrolling the whole window (rather than scrolling the scroller within the window). But that wouldn't make sense because then things like the DM page wouldn't work because the input box is at the bottom of the window.
Until someone can explain why Pinephone doesn't appear to be sending scroll events in either form then it's not going to get any better than keyboard navigation, unfortunately.
(Or if someone can tell me how to insert content above the widget while keeping the view frozen so that we're not doing the "make the box zero-height" kludge)
Improved solution for #164