[Bug]: Posts overflow their card

[daenney]

Describe the bug

For some reasons a number of posts seem to "escape" from the card they're rendered in.

I tried disabling and enabling the increased font size and line height options, but that doesn't change it.

Steps To Reproduce

I don't know exactly how to reproduce it, it just started happening. It's in this thread that it happens: https://en.osm.town/@opencage/111823092381561642. It seems to happen at random and so far it seems to only happen to @opencage@en.osm.town.

Logs and/or Screenshots

Instance Backend

GoToSocial

Operating System

Arch Linux

Package

Flatpak

Troubleshooting information

os: GNOME 45 (Flatpak runtime)
prefix: /app
flatpak: true
version: 0.6.2 (production)
gtk: 4.12.4 (4.12.4)
libadwaita: 1.4.2 (1.4.2)
libsoup: 3.4.4 (3.4.4)
libgtksourceview: 5.10.0 (5.10.0)

Additional Context

No response

[daenney]

It does render correctly in Feditext, and it seems to render fine in their Masto instance UI too, which prompted me to file the bug.

[GeopJr]

This is a regression due to #644 (I'll include more info for future reference, but the solution will be to partially revert one of the hacks)

• The above is reproducible when larger font size and line height are enabled (probably happens even without those on other posts, but for the above specifically that's the case)
• Setting natural_wrap_mode to Gtk.NaturalWrapMode.WORD, fixes most of the above but not all. https://en.osm.town/@opencage/111823180369571153 is one of them so further testing will happen on it.
• The hack from feat(LWW): remove hack #644 is ellipsize + lines. The reason that fixes it is because gtklabel measures the width differently based on the label's properties (ellipsize, wrap, natural_wrap_mode, use-markup, use-underline etc). https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtklabel.c

While most other labels have a bound width of ~532, the overflowing one has more than double

default:

ellipsize + lines 100 hack:

default + use-markup false:

I can't override most of the functions responsible for calculating the width and I don't want to re-create gtklabel in Vala https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtklabel.c

This is probably the culprit of #719 #632 #626

cc: @bugaevc in case you have any insights

[daenney]

That was a lot faster and more info than I was expecting, thank you! Seems that's going to be annoying to fix.

I'm still curious how it's only posts in that thread that manage to trigger it, but ah well.

[GeopJr]

Seems that's going to be annoying to fix.

I'm still curious how it's only posts in that thread that manage to trigger it, but ah well.

It's very much out of my expertise. It has to do with at least GTK's basic label widget and probably other circumstances that cause the label dimension (bounds) being incorrect.

The hack previously used would fix that by setting the label to ellipsize (adds ... at the end without displaying the whole content) and setting the desired lines it should use to 100 (so it doesn't actually ellipsize and show the whole content). That seemed to force the label to have a somewhat static size and would avoid the above issue. On #644 Sergey was fixing some low level GTK issues discovered through Tuba and the hacks were removed since they would conflict with it.

This issue was first brought to my attention on the comments of one of the early Tuba releases 😅 Before removing the hack I did check against those posts that caused it then and didn't seem to be an issue anymore but here we are again!

To report it to GTK I need to create at least a simple minimal reproducer but since the circumstances are so narrow (use-markup, larger font and line height, listbox with complicated nested widgets, label-with-widgets etc) it's going to take some time. That's why I tagged Sergey since he is familiar with both Tuba's and GTK's codebases in case he has any insights!

[bugaevc]

So FWIW (and I haven't read the details of this issue, yet): we know that GtkLabel is currently pretty broken, and I'm going to work on reworking how it does things wrt wrapping and ellipsizing and measurements.

So if you can make this into a reproducible test case, that'd help.

[GeopJr]

Done! Probably can be simplified further but this did it. FWIW, the stack was the last piece of the puzzle

public class ExampleApp : Adw.Application {
	public ExampleApp () {
		Object (
			application_id: "com.example.App",
			flags: ApplicationFlags.DEFAULT_FLAGS
		);
	}
  
	public override void activate () {
		var win = new Adw.ApplicationWindow (this);
		win.set_default_size (500, 300);

		var provider = new Gtk.CssProvider ();
		provider.load_from_string (".larger{font-size:larger;line-height:1.4;}.padding{padding:2px;}");
		Gtk.StyleContext.add_provider_for_display (Gdk.Display.get_default (), provider, Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION);

		var listbox = new Gtk.ListBox () {
			selection_mode = Gtk.SelectionMode.NONE,
			css_classes = {"background"}
		};

		var content_box = new Gtk.Box (Gtk.Orientation.VERTICAL, 0) {
			css_classes = {"card", "padding"},
		};
		content_box.append (new Gtk.Label ("") {
			width_request = 610,
			height_request = 34
		});

		var stack = new Gtk.Stack () {
			margin_top = 15,
			margin_start = 18,
			margin_end = 18,
			margin_bottom = 18
		};
		stack.add_child (new Gtk.Label ("and he <a href='https://en.osm.town/@SK53'>@SK53</a> keeps the momentum with the rarely seen combination of Rwanda 🇷🇼 Romania 🇷🇴 <a href='https://en.osm.town/tags/fridaygeotrivia'>#fridaygeotrivia</a> 👏") {
			use_markup = true,
			wrap = true,
			xalign = 0.0f,
			wrap_mode = Pango.WrapMode.WORD_CHAR,
			valign = Gtk.Align.START,
			ellipsize = Pango.EllipsizeMode.NONE,
			css_classes = {"larger"}
		});
		content_box.append (stack);
		listbox.append (content_box);
  
		win.content = new Gtk.ScrolledWindow () {
			vexpand = true,
			hscrollbar_policy = Gtk.PolicyType.NEVER,
			child = new Adw.Clamp () {
					child = listbox,
					tightening_threshold = 300,
					maximum_size = 670,
					vexpand = true
			}
		};
		win.present ();
	}
  
	public static int main (string[] args) {
		var app = new ExampleApp ();
		return app.run (args);
	}
}

valac --target-glib=2.74 --pkg gtk4 --pkg libadwaita-1 reproducer.vala && ./reproducer

[bugaevc]

I can't seem to reproduce this, I get a normal-looking layout from your example:

(I only had to remove the emoji, as there seems to be some bug on F40 that causes emoji to get HUGE. Please tell me if you can still reproduce on your end without emoji, or if they are important here.)

[GeopJr]

Yep, the emojis are important. In fact, everything is important, including the exact characters https://gitlab.gnome.org/GNOME/gtk/-/issues/6637

edit:

[bugaevc]

Looks fine with emoji too, save for the -- well, emoji.

Can you try with a fresh GTK from master?

[GeopJr]

Sorry for the wait, using gnome-nightly flatpak, which is on 4.15.0-c37e88d,

[bugaevc]

1. I can't seem to reproduce on a recent commit (latest main, a few commits past c37e88d) either. Hmm.

2. Partly off-topic, but also very related: could you please test this experimental branch? With this example, and with Tuba overall. You should:

   • set wrap
   • probably also set ellipsize and nat-lines -- but not to work around anything, but because we don't want overly long posts taking over the timeline

   The branch basically reworks label layout in presense of ellipsize / wrap / a line limit, to hopefully make it behave consistently and not break everything.

   Would be super cool if you could test it together with https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6569 too.