Description of problem: I don't know if it is a gnome-shell bug, or related to some other components (gtk?). Anyway one of the easiest ways to reproduce this bug is using gnome-text-editor. Also note that this bug doesn't happen if only gnome-text-editor is being run under fa_IR locale; you should log in to Gnome in fa_IR locale. Also happens in settings app. If you open gnome text editor, and print some chars so that it'll go in 'modified' state, and then try to close gnome-text-editor, it hangs (when it is supposed to ask if I want to save my changes). And it repeatedly prints the following error in the logs: Gtk-CRITICAL **: 13:52:43.425: gtk_widget_measure: assertion 'for_size >= -1' failed The same error happens if I go to gnome settings->keyboard and click the last box (keyboard shortcuts). Version-Release number of selected component (if applicable): gnome-shell-42.0-2.fc36.x86_64 gtk4-4.6.2-1.fc36.x86_64 How reproducible: 100% Steps to Reproduce: 1. Select "Persian" language in gnome settings 2. Logout and login again 3. Run gnome text editor 4. print a few chars 5. Try to close gnome text editor window Actual results: Gnome text editor hangs, and you'll need to force-kill it. You see following error in logs: Gtk-CRITICAL **: 13:52:43.425: gtk_widget_measure: assertion 'for_size >= -1' failed Expected results: Should show if I want to save or discard changes and then close normally. Additional info: Another reproduction: Open gnome settings, go to keyboard settings (صفحه کلید) and then click the last box to open keyboard shortcut settings.
Proposed as a Freeze Exception for 36-final by Fedora user hedayat using the blocker tracking app because: This bug causes some basic functionality to freeze in at least one locale (I'd guess it can happen in other locales too): text editor will freeze on closing when a new file is being edited; and clicking in at least one section of the gnome settings app will make it freeze completely.
Proposing as a blocker. This sounds like a conditional violation of the default application functionality criterion: https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality
I tried to reproduce the Gnome Text Editor behavior with no luck (maybe because my gtk and gnome-shell packages are slightly newer?). However, I can replicate the keyboard shortcut settings behavior.
(In reply to Ben Cotton from comment #3) > I tried to reproduce the Gnome Text Editor behavior with no luck (maybe > because my gtk and gnome-shell packages are slightly newer?). Maybe depends on window size.
So far I've only been able to replicate the keyboard shortcut settings hang with Persian. English (US), French, German, and Czech all work as expected. Chinese (Mandarin) does as well, but most of the strings were untranslated, so I'm not sure if that's a reliable indicator.
With current stable package versions, I'm unable to replicate any of aforementioned two issues under the fa_IR locale. gnome-shell-42.0-3.fc36.x86_64 gtk4-4.6.2-2.fc36.x86_64 Hedayat, can you update to latest packages and try again?
I also don't know how to reproduce this (with F36 RC1.1). Does anyone know of a corresponding upstream issue.
Could this be related to https://gitlab.gnome.org/GNOME/gtk/-/issues/4517?
Seems likely, yeah. We did run into that earlier in the cycle with GNOME Software; digging into the upstream issues and downstream builds, it looks like we backported a GNOME Software-specific workaround: https://src.fedoraproject.org/rpms/gnome-software/blob/f36/f/0002-app-row-no-multiline.patch but we did not adopt any fix/workaround on the GTK side yet. GNOME folks - Matthias, Michael - how do you feel about this issue, both this specific manifestation of it and the general concern that there may still be other cases of it lurking outside of the GNOME Software one we worked around?
Hey, this is random - another weird bug I happened to see on my new laptop is...*this bug*. If I boot F36 RC1 Workstation Live on it, *do not* connect to wifi, and try to run gnome-control-center, it never launches. Run from a console I see this same "for_size >= -1 failed" error (at "gnome-control-center:3900"). If I connect to the wifi, then g-c-c launches fine. The first pane it shows is the WiFi one, so presumably when I have no wifi connections that pane does something that triggers the problem. The laptop has a 1920x1200 internal display.
The best person to ask is Benjamin (Company), who I see you're discussing this with already in #fedora-desktop:matrix.org.
Here's Benjamin's proposed workaround: https://gitlab.gnome.org/GNOME/gtk/-/commit/90e372fb8e55fa2176d019dd5875a667ed8d3fbc.patch Here's a scratch build with Benjamin's proposed workaround: https://koji.fedoraproject.org/koji/taskinfo?taskID=86263154 Can folks who are able to reproduce this please test the scratch build and see how it behaves? Our expectation is that it should prevent apps from outright hanging, but the affected elements will likely appear a bit wrong - show up in the wrong place, overlap other elements, or be entirely off-screen.
Good news, the workaround does work for my gnome-control-center case. The expected warning message appears - the specific values it gives are "reports a minimum width of 18, but minimum width for height of 1048576 is 26". I don't see anything obviously overlapping or out of place - I guess the values imply a difference of 8 pixels which would be a bit hard to spot.
FEDORA-2022-a25fbbc152 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a25fbbc152
+5 in https://pagure.io/fedora-qa/blocker-review/issue/779 , marking accepted blocker. Note, this could still potentially be waived as a late blocker; we'll discuss that on Thursday at the Go/No-Go meeting. I will request an RC2 with the fix, and we can decide which to ship on Thursday (assuming no other blockers).
Yeah, I confirm that the proposed workaround fixes my problems without any apparent UI issues.
FEDORA-2022-a25fbbc152 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-a25fbbc152` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a25fbbc152 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks, Hedayat - marking VERIFIED, then. Could you give the update some karma too?
(In reply to Adam Williamson from comment #18) > Thanks, Hedayat - marking VERIFIED, then. Could you give the update some > karma too? Tested now on VM, with persian language. Update is working fine.
Sorry for being somewhat late, but I added my karma. Thanks for all the work everybody. :) And sorry for not raising the issue's visibility sooner; I thought filling the bug should make it visible enough :(
That's quite OK, we actually knew about it before from the GNOME Software case anyway; it just sort of fell off my radar that the general issue still existed after we worked around the known gnome-software trigger :|
FEDORA-2022-a25fbbc152 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days