GNOME Bugzilla – Bug 784314
entry completion regression on wayland
Last modified: 2018-05-02 18:39:21 UTC
I've noticed with Epiphany while on Rawhide that the URL entry completion exhibits some weird behavior. I tested on Xorg and did not have the same behavior, so I'm assuming this is an issue in Gtk+ directly and not Epiphany. gtk3-3.22.16-1.fc27.x86_64 epiphany-3.25.2-1.fc27.x86_64 When typing in the URL entry a website I have previously visited, things start out fine. So say I start typing "twitter.". Everything is good, I see various completion items in the GtkEntryCompletion window. Then i type "twitter.f", which has no entries to match. Still, things are fine in that I can see the text I'm typing. Now it gets weird. If I continue to type "twitter.fffff" I only see "twitter.f". But if I move my mouse over the GtkEntryCompletion window, the resulting "ffff" text will show up. Again, this doesn't happen under Xorg, so I'd guess it has to do with some of the weirdness in GtkEntry w/ Wayland/subsurface/popup-window type stuff. I'd submit a test-case, but "just run Epiphany on Wayland" is probably enough?
This seems caused by commit 5cb5baa7d on Mutter.
(In reply to Carlos Garnacho from comment #1) > This seems caused by commit 5cb5baa7d on Mutter. Reverting 5cb5baa7d fixes the issue for me too.
*** Bug 784488 has been marked as a duplicate of this bug. ***
*** Bug 788140 has been marked as a duplicate of this bug. ***
Created attachment 360912 [details] [review] wayland: Queue empty area redraws if there was no damage area After wl_surface.commit, a surface actor may be redrawn if there was a pending wl_surface.damage, resized if any other property resulted in a different layout, or none of the above if whatever state is applied results in the same size. For this last case, Clutter won't hit the repaint machinery, so there may be frame callbacks that won't be dispatched until anything is actually redrawn on screen. Since we want these frame callbacks to run after wl_surface.commit, queue a redraw on the surface actor with an empty clip area, in order to ensure a stage redraw will be queued.
Review of attachment 360912 [details] [review]: This doesn't look right to me. Applying a state shouldn't imply we always will redraw, as applying a state can mean things that doesn't affect drawing at all (such as changing the title, asking to be maximized, etc). If there is no damage attached, I don't think a client should be able to rely on getting a frame callback since there is no reason for the compositor to redraw anything.
Created attachment 361003 [details] [review] gdk/wayland: Avoid idempotent wl_subsurface.set_position calls These may not result on wl_surface.frame callbacks, yet we do trigger a frame clock tick that would get stuck on the lack of such callback.
This fixes it on the gtk+ side, although it's funny that it also used to work on weston...
I confirm the 361003 gtk3 patch fixes the Epiphany issue for me.
So we really need mutter fixed ASAP, like several weeks ago. Any problems with pushing this and making a release?
*** Bug 789031 has been marked as a duplicate of this bug. ***
Review of attachment 361003 [details] [review]: lgtm.
(In reply to Carlos Garnacho from comment #8) > This fixes it on the gtk+ side, although it's funny that it also used to > work on weston... My suspicion would be that weston is more redraw prone. (In reply to Michael Catanzaro from comment #10) > So we really need mutter fixed ASAP, like several weeks ago. Any problems > with pushing this and making a release? FWIW, the patch that fixes the issue is for GTK+.
Attachment 361003 [details] pushed as 8aa6d59 - gdk/wayland: Avoid idempotent wl_subsurface.set_position calls
This commits break totem's subsurface positioning.
Created attachment 361772 [details] screenshot issue This seems to only happen when the window is maximized or fullscreen.
OK, can I ask that the mutter optimization be reverted until we figure this out? This is the sort of thing that needs to be sorted out in the current development cycle at this point, not at the expense of GNOME 3.26 users.
Any plans on reverting 8aa6d59b7a214ba03a83bcae8c43712f8e402927 while people investigate the popup issue?
(In reply to Lionel Landwerlin from comment #18) > Any plans on reverting 8aa6d59b7a214ba03a83bcae8c43712f8e402927 while people > investigate the popup issue? Due to the severity and urgency of the issue, I've reverted that commit on both gtk-3-22 and master, and also reverted mutter 5cb5baa7d on both gnome-3-26 and master.
And as a followup, I reverted a test change for mutter that depended on 5cb5aa7d on both the gnome-3-26 and master branches.
(In reply to Lionel Landwerlin from comment #16) > Created attachment 361772 [details] > screenshot issue > > This seems to only happen when the window is maximized or fullscreen. Does it also happen on weston? If such patch results on mispositioned subsurfaces, it would seem mutter is failing to propagate the position change to subsurfaces.
(In reply to Carlos Garnacho from comment #21) > (In reply to Lionel Landwerlin from comment #16) > > Created attachment 361772 [details] > > screenshot issue > > > > This seems to only happen when the window is maximized or fullscreen. > > Does it also happen on weston? If such patch results on mispositioned > subsurfaces, it would seem mutter is failing to propagate the position > change to subsurfaces. Same problem on weston. Again, just when the windows is fullscreen.
*** Bug 789127 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/844.