Threading UI: Cannot scroll back to or access tweets that the current tweet is a reply to

[siebenmann]

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.

[IBBoard]

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]

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]

Easy enough patch:

diff --git a/src/TweetInfoPage.vala b/src/TweetInfoPage.vala
index 813bafa0..426ee518 100644
--- a/src/TweetInfoPage.vala
+++ b/src/TweetInfoPage.vala
@@ -159,7 +159,9 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {

     mm_widget.media_clicked.connect ((m, i) => TweetUtils.handle_media_click (tweet.get_medias (), main_window, i));
     this.scroll_event.connect ((evt) => {
+      debug("Scrolling...");
       if (evt.delta_y < 0 && this.vadjustment.value == 0 && tweet.is_reply()) {
+        debug("Scroll delta: %f; vadjustment %f, container size: %d", evt.delta_y, this.vadjustment.value, max_size_container.max_size);
         int inc = (int)(vadjustment.step_increment * (-evt.delta_y));
         max_size_container.max_size += inc;
         return true;
@@ -728,6 +730,7 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {
    */
   private void load_replied_to_tweet (int64 reply_id) {
     if (reply_id == 0) {
+      debug("Hit the top of a thread");
       // Top of the thread, so stop
       return;
     }
@@ -739,6 +742,7 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {
     }

     if (replied_to_idx != -1) {
+      debug("Already had %lld in thread", reply_id);
       // We already have this tweet, so don't fetch it from the web
       // BUT we might not have the rest of the thread (because they pressed "Back" after we removed some of the thread)
       // so recurse anyway
@@ -763,6 +767,7 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {
         call.invoke_async.end (res);
       } catch (GLib.Error e) {
         var err = TweetUtils.failed_request_to_error (call, e);
+        debug("Failed to load replied-to tweet %lld - %d:$d", reply_id, err.domain, err.code);
         if (err.domain == TweetUtils.get_error_domain()) {
           if (err.code == 179) {
             missing_tweet_label.label = _("This tweet is hidden by the author");
@@ -790,6 +795,7 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {
       /* If we get here, the tweet is not protected so we can just use it */
       var tweet = new Cb.Tweet ();
       tweet.load_from_json (parser.get_root (), account.id, new GLib.DateTime.now_local ());
+      debug("Loaded replied-to tweet %lld", reply_id);
       replied_to_list_box.model.add (tweet);
       if (tweet.retweeted_tweet == null)
         load_replied_to_tweet (tweet.source_tweet.reply_id);

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

(cawbird:12811): cawbird-DEBUG: 19:58:03.471: REST: GET 1.1/statuses/show.json?include_my_retweet=true&id=1271508939474157570&tweet_mode=extended
(cawbird:12811): cawbird-DEBUG: 19:58:03.471: REST: GET 1.1/search/tweets.json?include_entities=false&q=to:FoundGolfClubs from:FoundGolfClubs&count=100&since_id=1271508939474157570
(cawbird:12811): cawbird-DEBUG: 19:58:03.471: REST: GET 1.1/search/tweets.json?include_entities=false&q=to:FoundGolfClubs -from:FoundGolfClubs&count=100&since_id=1271508939474157570
(cawbird:12811): cawbird-DEBUG: 19:58:03.649: REST: POST 1.1/statuses/lookup.json?include_entities=true&id=&tweet_mode=extended
(cawbird:12811): cawbird-DEBUG: 19:58:03.862: TweetInfoPage.vala:798: Loaded replied-to tweet 1271500112821395456
(cawbird:12811): cawbird-DEBUG: 19:58:03.870: TweetInfoPage.vala:733: Hit the top of a thread
(cawbird:12811): cawbird-DEBUG: 19:58:03.880: REST: POST 1.1/statuses/lookup.json?include_entities=true&id=1271516528224108545,1271513360530640898&tweet_mode=extended
(cawbird:12811): cawbird-DEBUG: 19:58:04.805: TweetInfoPage.vala:162: Scrolling...
(cawbird:12811): cawbird-DEBUG: 19:58:04.806: TweetInfoPage.vala:164: Scroll delta: -1.000000; vadjustment 0.000000, container size: 0
(cawbird:12811): cawbird-DEBUG: 19:58:04.829: TweetInfoPage.vala:162: Scrolling...
(cawbird:12811): cawbird-DEBUG: 19:58:04.829: TweetInfoPage.vala:164: Scroll delta: -1.000000; vadjustment 0.000000, container size: 132
(cawbird:12811): cawbird-DEBUG: 19:58:04.853: TweetInfoPage.vala:162: Scrolling...
(cawbird:12811): cawbird-DEBUG: 19:58:04.853: TweetInfoPage.vala:164: Scroll delta: -1.000000; vadjustment 0.000000, container size: 264
(cawbird:12811): cawbird-DEBUG: 19:58:05.141: TweetInfoPage.vala:162: Scrolling...
(cawbird:12811): cawbird-DEBUG: 19:58:05.142: TweetInfoPage.vala:164: Scroll delta: -1.000000; vadjustment 0.000000, container size: 396
(cawbird:12811): cawbird-DEBUG: 19:58:05.181: TweetInfoPage.vala:162: Scrolling...
(cawbird:12811): cawbird-DEBUG: 19:58:05.181: TweetInfoPage.vala:164: Scroll delta: -1.000000; vadjustment 0.000000, container size: 528

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 cawbird to see the debug (depending on whether your RPM builds as a debug build or not).

[siebenmann]

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:

(cawbird:3320654): cawbird-DEBUG: 15:10:57.176: TweetInfoPage.vala:164: Scroll info: 0.000000; vadjustment 0.000000, container size: 0

[IBBoard]

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]

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: 0 with varying vadjustment values but always 0 for the others. The vadjustment goes up when I scroll down, and down when I scroll up,

[IBBoard]

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]

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]

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!

Some GDK backends can also generate “smooth” scroll events, which can be recognized by the gdk_scroll_smooth scroll direction. For these, the scroll deltas can be obtained with get_scroll_deltas.

(https://valadoc.org/gdk-3.0/Gdk.EventScroll.html)

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.

diff --git a/src/TweetInfoPage.vala b/src/TweetInfoPage.vala
index 813bafa0..a7577e42 100644
--- a/src/TweetInfoPage.vala
+++ b/src/TweetInfoPage.vala
@@ -159,8 +159,11 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {

     mm_widget.media_clicked.connect ((m, i) => TweetUtils.handle_media_click (tweet.get_medias (), main_window, i));
     this.scroll_event.connect ((evt) => {
-      if (evt.delta_y < 0 && this.vadjustment.value == 0 && tweet.is_reply()) {
-        int inc = (int)(vadjustment.step_increment * (-evt.delta_y));
+      double evt_delta_x, evt_delta_y;
+      evt.get_scroll_deltas(out evt_delta_x, out evt_delta_y);
+
+      if (evt_delta_y < 0 && this.vadjustment.value == 0 && tweet.is_reply()) {
+        int inc = (int)(vadjustment.step_increment * (-evt_delta_y));
         max_size_container.max_size += inc;
         return true;
       }

[siebenmann]

Unfortunately this still doesn't scroll, and reports that the new evt_delta_y is 0.

[IBBoard]

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]

I've installed fvwm2-2.6.9 with this patch:

diff --git a/src/TweetInfoPage.vala b/src/TweetInfoPage.vala
index a7577e42..1d4deeac 100644
--- a/src/TweetInfoPage.vala
+++ b/src/TweetInfoPage.vala
@@ -159,8 +159,30 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {

     mm_widget.media_clicked.connect ((m, i) => TweetUtils.handle_media_click (tweet.get_medias (), main_window, i));
     this.scroll_event.connect ((evt) => {
+      debug("Event type: %s", evt.get_event_type().to_string());
       double evt_delta_x, evt_delta_y;
-      evt.get_scroll_deltas(out evt_delta_x, out evt_delta_y);
+      var success = evt.get_scroll_deltas(out evt_delta_x, out evt_delta_y);
+      if (!success) {
+        debug("Failed to get deltas");
+      }
+      else {
+        debug("evt_delta_y: %f", evt_delta_y);
+      }
+
+      Gdk.ScrollDirection scroll_dir;
+      success = evt.get_scroll_direction(out scroll_dir);
+      if (!success) {
+        debug("Failed to get scroll direction");
+      }
+      else if (scroll_dir == Gdk.ScrollDirection.UP) {
+        debug("Scroll direction up");
+      } else if (scroll_dir == Gdk.ScrollDirection.DOWN) {
+        debug ("Scroll direction down");
+      } else {
+        debug("Unknown scroll direction");
+      }
+
+

       if (evt_delta_y < 0 && this.vadjustment.value == 0 && tweet.is_reply()) {
         int inc = (int)(vadjustment.step_increment * (-evt_delta_y));

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]

What I see reported from your patch is:

(cawbird:3808806): cawbird-DEBUG: 16:19:31.855: TweetInfoPage.vala:162: Event type: GDK_SCROLL
(cawbird:3808806): cawbird-DEBUG: 16:19:31.855: TweetInfoPage.vala:166: Failed to get deltas
(cawbird:3808806): cawbird-DEBUG: 16:19:31.855: TweetInfoPage.vala:177: Scroll direction up

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, xev reports:

ButtonPress event, serial 33, synthetic NO, window 0x9000001,
    root 0x155, subw 0x0, time 82853852, (88,90), root:(651,472),
    state 0x0, button 4, same_screen YES

ButtonRelease event, serial 33, synthetic NO, window 0x9000001,
    root 0x155, subw 0x0, time 82853852, (88,90), root:(651,472),
    state 0x800, button 4, same_screen YES

ButtonPress event, serial 33, synthetic NO, window 0x9000001,
    root 0x155, subw 0x0, time 82854292, (88,90), root:(651,472),
    state 0x0, button 5, same_screen YES

ButtonRelease event, serial 33, synthetic NO, window 0x9000001,
    root 0x155, subw 0x0, time 82854292, (88,90), root:(651,472),
    state 0x1000, button 5, same_screen YES

(Button 4 is up, button 5 is down.)

[IBBoard]

Okay, something is really odd if it thinks it got a valid direction (success is 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, xev is 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]

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 xev prints, 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.

[siebenmann]

As an experiment, I tried the patched cawbird on my laptop (with a touchpad). Trying to scroll up on a tweet that was a reply with the touchpad reported that it saw GDK_SCROLL events, they had an evt_delta_y (so it could get the scroll deltas), the raw evt.delta_y is non-zero, and that it failed to get the scroll direction. Scrolling up to the original tweet(s) works, and since evt.delta_y is non-zero it probably also works on an un-patched cawbird.

For me, xev on my laptop touchpad reports the same sort of X event information as on my desktop with a mouse; I don't get the additional Mod2 modifier that you do.

[IBBoard]

Ah, sorry. I saw "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" and read "I get these log messages whether I'm scrolling up or down". My bad.

I don't know why xev thought I had Mod2 active. I thought I was just scrolling.

From what you've said then it sounds like I might be able to check for delta using the function and if that fails then look for the direction and use a fixed scale factor (rather than using delta_y). Hopefully there's nothing that fails on both or else I'm lost as to what we can rely on! I'll try to patch it soon.

[IBBoard]

Can you test the new branch? I think that should work from what you've said.

[siebenmann]

The new branch works for me on both a physical mouse with a scroll wheel and on my laptop with a touchpad. Since I have a spare mouse and had dragged out the laptop anyway, I tried the mouse with cawbird on the laptop and it did scroll correctly when viewing a single tweet, in both the old 1.0.5 cawbird and master. My laptop runs the Cinnamon desktop (although I was ssh'd in to my desktop), and on it with the mouse the debugging reports that it's a GDK_SCROLL event, the evt.delta_y is -1, it can't get a scroll direction, but it can get the delta (and the y delta is still -1).

I'm puzzled by what would be different about my fvwm environment. Possibly I haven't done some magic Xinput/Linux event configuration that Cinnamon does. (I don't have a touchpad-free desktop environment with Cinnamon that I can test on to see if it behaves even without a touchpad.)

[IBBoard]

There we go, that's merged now. I'll try to remember to patch the OBS builds in the next few days.

[siebenmann]

I found a test program here. On my desktop under fvwm, it reports that I'm seeing only GDK_SCROLL_UP and GDK_SCROLL_DOWN events and they have 0 delta, and they come from the 'Core Pointer' scroll device. On my laptop, the touchpad generates only GDK_SCROLL_SMOOTH events (with non-zero y deltas for vertical scrolling of various amounts), while the mouse scroll wheel generates both GDK_SCROLL_SMOOTH events (with either +1 or -1 y deltas) and GDK_SCROLL_UP/DOWN events (with 0 delta). The laptop reports specific devices for both the touchpad and the mouse, instead of 'Core Pointer'.

[IBBoard]

I assumed it might be something like that based on what I'd read. But when "scroll direction" wasn't reporting "SMOOTH" and all the events were reporting "GTK_SCROLL" then I wasn't sure.

It still feels like the API should behave a little differently in some places (the whole point of the functions being that they do calculations to make things consistent) but never mind. At least it is fixed.

If only I could work out how to make it more accessible and just lock the scroll to the widget as things were added above (so that you've got a representative scroll bar), rather than having a work-around of a zero-height box that expands as you scroll up.

[JayVii]

This issue still persists for me (on the pinephone), even when compiled from git directly.

[IBBoard]

Huh. That must mean that the phone isn't sending the right events when you scroll.

If you can give me some logging with this patch then I might be able to debug something, but it might just be that mobile gives nothing usable.

Ideally I'd be able to find a way to insert objects above the main tweet without causing everything else to move, but I've looked into that for hours and found no methods that worked and no documentation online from people trying to do the same thing.

[JayVii]

Excuse my ignorance, but I am not entirely sure how to apply your patch to the git sources I checked out on my phone? :/

[IBBoard]

Sorry, I assumed "compiled from git" meant you were familiar with patching etc.

Save the patch as a file (everything in the code block from diff --git to the end) and then run git apply the-file.patch. Alternatively, patch -p1 < the-file.patch should work.

[JayVii]

Sorry for the late reply, unfortunately, the patch not not be applied for some reason (I tried both ways suggested by you):

mobian@mobian:~/.local/cawbird$ git apply touchpatch.patch
error: patch failed: src/TweetInfoPage.vala:159
error: src/TweetInfoPage.vala: patch does not apply

mobian@mobian:~/.local/cawbird$ patch -p1 < touchpatch.patch 
patching file src/TweetInfoPage.vala
Hunk #1 FAILED at 159.
1 out of 1 hunk FAILED -- saving rejects to file src/TweetInfoPage.vala.rej

For the later, the rejects are:

--- src/TweetInfoPage.vala
+++ src/TweetInfoPage.vala
@@ -159,8 +159,30 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {

     mm_widget.media_clicked.connect ((m, i) => TweetUtils.handle_media_click (tweet.get_medias (), main_window, i));
     this.scroll_event.connect ((evt) => {
+      debug("Event type: %s", evt.get_event_type().to_string());
       double evt_delta_x, evt_delta_y;
-      evt.get_scroll_deltas(out evt_delta_x, out evt_delta_y);
+      var success = evt.get_scroll_deltas(out evt_delta_x, out evt_delta_y);
+      if (!success) {
+        debug("Failed to get deltas");
+      }
+      else {
+        debug("evt_delta_y: %f", evt_delta_y);
+      }
+
+      Gdk.ScrollDirection scroll_dir;
+      success = evt.get_scroll_direction(out scroll_dir);
+      if (!success) {
+        debug("Failed to get scroll direction");
+      }
+      else if (scroll_dir == Gdk.ScrollDirection.UP) {
+        debug("Scroll direction up");
+      } else if (scroll_dir == Gdk.ScrollDirection.DOWN) {
+        debug ("Scroll direction down");
+      } else {
+        debug("Unknown scroll direction");
+      }
+
+

       if (evt_delta_y < 0 && this.vadjustment.value == 0 && tweet.is_reply()) {
         int inc = (int)(vadjustment.step_increment * (-evt_delta_y));

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]

Looks like the patch is based on 27f572e9bd84f02d22f4ce3b878fc64be395ced2 - 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:

diff --git a/src/TweetInfoPage.vala b/src/TweetInfoPage.vala
index 24b2bb1d..70c3f7b1 100644
--- a/src/TweetInfoPage.vala
+++ b/src/TweetInfoPage.vala
@@ -179,12 +179,24 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {

     mm_widget.media_clicked.connect ((m, i) => TweetUtils.handle_media_click (tweet.get_medias (), main_window, i));
     this.scroll_event.connect ((evt) => {
+      debug("Event type: %s", evt.get_event_type().to_string());
       double evt_delta_x, evt_delta_y;
       var success = evt.get_scroll_deltas(out evt_delta_x, out evt_delta_y);

       if (!success) {
+        debug("Failed to get deltas");
         Gdk.ScrollDirection scroll_dir;
         success = evt.get_scroll_direction(out scroll_dir);
+        if (!success) {
+          debug("Failed to get scroll direction");
+        }
+        else if (scroll_dir == Gdk.ScrollDirection.UP) {
+          debug("Scroll direction up");
+        } else if (scroll_dir == Gdk.ScrollDirection.DOWN) {
+          debug ("Scroll direction down");
+        } else {
+          debug("Unknown scroll direction");
+        }

         if (success && scroll_dir == Gdk.ScrollDirection.UP) {
           evt_delta_y = -1;
@@ -193,6 +205,8 @@ class TweetInfoPage : IPage, ScrollWidget, Cb.MessageReceiver {
         }
       }

+      debug("evt_delta_y: %f", evt_delta_y);
+
       if (evt_delta_y < 0 && this.vadjustment.value == 0 && tweet.is_reply()) {
         int inc = (int)(vadjustment.step_increment * (-evt_delta_y));
         max_size_container.max_size += inc;

I suspect you'll see:

Event type: xxx
Failed to get deltas
Failed to get scroll direction
evt_delta_y: 0

And then someone needs to find out why your platform is sending/setting neither direction nor delta.

[JayVii]

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:

(cawbird:5274): cawbird-DEBUG: 23:50:40.939: MainWindow.vala:60: Focus widget now: TweetListEntry 0xaaaad70ebf40
(cawbird:5274): cawbird-DEBUG: 23:50:40.946: REST: GET 1.1/statuses/show.json?include_my_retweet=true&id=[REDACTED]&tweet_mode=extended&include_ext_alt_text=true
(cawbird:5274): cawbird-DEBUG: 23:50:40.948: REST: GET 1.1/search/tweets.json?include_entities=false&q=to:[REDACTED] from:[REDACTED]&count=100&since_id=[REDACTED]
(cawbird:5274): cawbird-DEBUG: 23:50:40.950: REST: GET 1.1/search/tweets.json?include_entities=false&q=to:[REDACTED] -from:[REDACTED]&count=100&since_id=[REDACTED]
(cawbird:5274): cawbird-DEBUG: 23:50:40.952: MainWindow.vala:60: Focus widget now: TextButton 0xaaaad4332f80
(cawbird:5274): cawbird-DEBUG: 23:50:41.143: REST: POST 1.1/statuses/lookup.json?include_entities=true&id=&tweet_mode=extended&include_ext_alt_text=true
(cawbird:5274): cawbird-DEBUG: 23:50:41.394: REST: POST 1.1/statuses/lookup.json?include_entities=true&id=[REDACTED]&tweet_mode=extended&include_ext_alt_text=true

And when i try to scroll (swipe up or down the screen), obviously with nothing happening:

(cawbird:5274): cawbird-DEBUG: 23:50:48.420: MainWindow.vala:60: Focus widget now: GtkLabel 0xaaaad43eb5a0

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]

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]

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]

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]

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]

No, it does not give any output when scrolling, unless new tweets have to be fetched.

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

Maybe scrolling up for the parent tweet is not the best option after all. There could be an additional Button next to each tweet … which when pressed opens the parent tweet as if one had opened that parent tweet from the timeline directly.

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]

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

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

This is a valid concern, I am not sure either on how to approach this.

[IBBoard]

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.

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.

[JayVii]

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]

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)