GNOME Bugzilla – Bug 788140
mutter optimization broke Epiphany's address bar
Last modified: 2017-09-30 13:13:46 UTC
I've already reported this issue on Debian BTS: https://bugs.debian.org/875826 and there's something similar for Ubuntu: https://launchpad.net/bugs/1719043 Running Debian unstable/sid with few packages from experimental (merely for GNOME 3.26). Thanks.
@Matteo from our discussion on IRC: https://paste.gnome.org/p0srnvwb7 The first line says clearly that it's related to the sync service. The seconds line that says "Message: received an invalid or unencryptable secret" is an error message that comes from libsecret when a fail occurs when decrypting the encrypted keyring-stored value into a SecretValue. More precisely, when AES fails to unpad the decrypted bytes. The rest of the lines are the result of the decryption failure which causes secret_item_get_secret() to return NULL, and that NULL to propagate to secret_value_get_text() and further. The place to look is load_secrets_cb() in ephy-sync-service.c. The quick fix is to abort the loading if secret_item_get_secret() returns NULL and report the error back to the user. My first thought was that libsecret fails to read the secret only from the WebKitWebProcess, because we don't see any criticals coming from the UI process in the paste. But if the UI process would've read them successfully, then the "Failed to get records in collection bookmarks. Status code: 400, response: 1" wouldn't be there. And @Matteo confirmed it to me on IRC that criticals appeared in the UI process too: <givascu> mfv: https://paste.debian.net/987736/ did you happen to see the same criticals coming from the UI process too? <mfv> yep. once. I'm still not sure though why libsecret would fail decrypting the secret, once it encrypted and stored it successfully.
Created attachment 360393 [details] [review] sync-service: Handle the case when secret_item_get_secret() returns NULL
Review of attachment 360393 [details] [review]: I'm gonna go ahead and accept this myself, since Michael is offline.
Attachment 360393 [details] pushed as 7963315 - sync-service: Handle the case when secret_item_get_secret() returns NULL
(In reply to Gabriel Ivașcu from comment #3) > Review of attachment 360393 [details] [review] [review]: > > I'm gonna go ahead and accept this myself, since Michael is offline. *and since it's a small patch.
Thanks @Matteo for all your patience and help on IRC to debug this.
This patch applied to 3.26.0 is not enough to fix this bug. (Tested on Ubuntu 17.10 Beta).
I've never signed in to Firefox Sync using Epiphany.
Hmm OK, so the lag has nothing to do with the sync service. Seems that Matteo's paste helped us uncover an existing issue in the sync service code, but not to identify the real source of the lag. Maybe the lag could be caused by something related to the recent changes in Epiphany's search provider? Michael would know more about this.
Epiphany browser mode does not use the search provider at all, so that's not it. So far we've eliminated bookmarks, history, and search engines as possible causes on IRC. Which is everything I can think to check. We're going to need a bisect done by somebody who can reproduce the issue. All the big changes that could affect this that immediately come to mind are in master and not gnome-3-26. I'm still concerned that typing in the overview was causing HTTP requests for sync.
Putting this into the NEEDINFO state because unfortunately none of the developers can reproduce the issue; we're not going to be able to fix it without more information.
Confirming this issue on Archlinux + Gnome 3.26 Wayland. The issue makes browser impossible to use. The issue also happens on Epiphany 3.24.3. The issue does not happen on weston or when launched with GDK_BACKEND=x11 epiphany. Also, the issue does not happen if moving mouse rapidly on the "Search with ..." dropdown.
We're going to need a bisect done by somebody who can reproduce the issue.
There is nothing to bisect as this is a new issue with Gnome 3.26 Wayland.
Sorry, I want to help, but I can't reproduce the problem, and we've eliminated all the likely suspects as possible causes. So until someone who can reproduce the issue can figure out which commit introduced the regression, there's unlikely to be any progress on this issue. A git bisect is the easiest way to do that. Alternatively, if you don't want to build from git, you could bisect between just the 3.25.x releases to at least narrow down the problem to a smaller range of commits: if we're lucky that would be enough to guess the problematic commit.
git bisect is not is possible given the number of packages for Gnome 3.26. The issue can be in any of them. However, if I replace in lib/widgets/ephy-location-entry.c gtk_entry_completion_set_model (completion, model); with GtkListStore *ls = gtk_list_store_new(1, G_TYPE_STRING); GtkTreeIter iter; int i; char buf[3]; for(i=0; i<3; i++) { gtk_list_store_append(ls, &iter); sprintf(buf, "%d", i); gtk_list_store_set(ls, &iter, 0, buf, -1); } gtk_entry_completion_set_model (completion, GTK_TREE_MODEL(ls)); The issue disappears. Of course, history/bookmarks no longer work.
Also, the issue does not happen if there are entries in the history or bookmarks sections of the dropdown when typing.
If you downgrade to Epiphany 3.24, does the issue still persist? I'm starting to suspect there may be a regression in mutter.
The issue also happens on Epiphany 3.24.3. The issue does not happen on weston or when launched with GDK_BACKEND=x11 epiphany
If (and only if) you're confident in your ability to recover a borked system from the command line (by switching to a tty and reinstalling the packages), try downgrading to mutter 3.24. You might need to downgrade gnome-shell as well. See if that fixes it.
Issue does not happen on mutter 3.24. According to git bisect 5cb5baa7d42712f9e0db8dfaa0485e2d833e4d83 is the first bad commit commit 5cb5baa7d42712f9e0db8dfaa0485e2d833e4d83 Author: Carlos Garnacho <carlosg@gnome.org> Date: Sun Apr 30 18:29:19 2017 +0200 ClutterActor: Optimize away idempotent scale/position updates If the actor results in the same scale/position, there's no need to trigger a transition. https://bugzilla.gnome.org/show_bug.cgi?id=782344 :040000 040000 26a816c35b1e4effb024d3793b687532dadc344e 31c7c994eedf27bde5ab2d7dfec1e95b22362d1a M clutter
Awesome, thanks for the bisection! I will summon Garnacho.
(In reply to Archlinux Bug from comment #12) > The issue does not happen on weston That was our first clue real. I should have paid more attention to that comment. :) I see you tried a lot to narrow this down, thanks!
*real clue
*** This bug has been marked as a duplicate of bug 784314 ***