GNOME Bugzilla – Bug 771540
Google Inbox shows no images when used as Web Application
Last modified: 2016-09-22 16:57:56 UTC
Created attachment 335716 [details] Google Inbox as web app (background) and as normal tab (foreground) I made a Web Application for Google Inbox. When I open it, the attached images are not shown for mails, just a symbol indicating that the image couldn't be loaded/displayed. When I open the very same page in a usual GNOME Web browser tab, everything works as expected. See the attached screenshot. The window in the background is Google Inbox opened as Web Application, the window in the foreground shows GNOME Web with a tab showing Google Inbox. As you can see, there the images are displayed normally.
(In reply to Tassilo Horn from comment #0) > Created attachment 335716 [details] > Google Inbox as web app (background) and as normal tab (foreground) > > I made a Web Application for Google Inbox. When I open it, the attached > images are not shown for mails, just a symbol indicating that the image > couldn't be loaded/displayed. Hm, this is strange. Can you please right click on the page, open the web inspector, and look for any errors. There will be a red circle with a little line through it if any errors are present, next to the warning triangle (which will probably be yellow, because there are almost always warnings). Also, please run Epiphany in a terminal and paste any warnings you see there. There are some criticals that I need to fix, so it's expected to see a few, but maybe there will be something I'm not expecting to see. To get the command to launch Epiphany as a web app in your terminal, you'll need to open its desktop file in ~/.local/share/applications and copy it from the Exec line.
Ok, here's the console output: % epiphany --application-mode --profile="/home/horn/.config/epiphany/app-epiphany-google-inbox-ab026cf61329c00f3c95eb85600cc59e7879393d" 'https://inbox.google.com/?pli=1' (epiphany-google-inbox-ab026cf61329c00f3c95eb85600cc59e7879393d:2990): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed (epiphany-google-inbox-ab026cf61329c00f3c95eb85600cc59e7879393d:2990): GLib-GObject-CRITICAL **: g_object_set_qdata: assertion 'G_IS_OBJECT (object)' failed (epiphany-google-inbox-ab026cf61329c00f3c95eb85600cc59e7879393d:2990): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion 'GTK_IS_ACTION (action)' failed (epiphany-google-inbox-ab026cf61329c00f3c95eb85600cc59e7879393d:2990): Gtk-CRITICAL **: gtk_action_set_visible: assertion 'GTK_IS_ACTION (action)' failed And about the inspector: that seems to be disabled in the Web Application mode. When I right-click, I only get the context menu entries Back, Forward, and Reload. In the normal browser tab, I also have "Inspect Element" (and more), but there it's of no use cause it works there...
Oh, when I simply remove the --application-mode switch from the command line args but keep the --profile, then the images also don't show up but the images are still broken. And there I have the Inspect Element entry. When I go to the debugger in the inspector, there's this error: Blocked a frame with origin "https://hangouts.google.com" from accessing a frame with origin "https://inbox.google.com". Protocols, domains, and ports must match. But that's also in the normal browser tab. There's also a second error: Failed to load resource: the server responded with a status of 404 (Not Found) The resource seems to be https://clients6.google.com/discovery/v1/apis/drive/v2internal/rest?fields=kind%2Cname%2Cversion%2CrootUrl%2CservicePath%2Cresources%2Cparameters%2Cmethods&pp=0&key=AIzaSyBMETqAdBPmHu53JDCA-q3-eXrtGGVSwLc But again, that's also in the normal browser tab.
Nothing looks suspicious. :/ Unfortunate that both of the Google bugs occur outside of app mode....
Hi Michael, first of all, I have solved the issue. In the --profile directory /home/horn/.config/epiphany/app-epiphany-google-inbox-ab026cf61329c00f3c95eb85600cc59e7879393d I deleted the cookies.sqlite file and restarted my Google Inbox Web Application. Then I was presented with the Google login screen where I had to re-perform the 2-step verification process. Thereafter, the images in the Google Inbox did appear, and after restarting the Web Application several times, they are still there. Of course, that's not a general solutions which users should have to perform after creating a Web Application for Inbox but at least I have narrowed it down to the cookies.sqlite file. Probably that has some missing entries... Hm, when I check the database's single table moz_cookies, there are 37 rows in it, many with accounts.google.com, o.mail.google.com and more. Maybe when creating a Web App only the cookies for the current domain (inbox.google.com in my case) are copied over? That would be kind of related to that other error I got: Blocked a frame with origin "https://hangouts.google.com" from accessing a frame with origin "https://inbox.google.com". Protocols, domains, and ports must match. I'm not sure, but aren't the protocols, domains, and ports equal here and only the host names are different?
(In reply to Tassilo Horn from comment #5) > Hm, when I check the database's single table moz_cookies, there are 37 rows > in it, many with accounts.google.com, o.mail.google.com and more. Maybe > when creating a Web App only the cookies for the current domain > (inbox.google.com in my case) are copied over? Yes. Good job, that's probably it. The code for this is in lib/ephy-web-app-utils.c. It raises the question: what SHOULD we do here? We probably don't want to copy over cookies from third-party domains. Should we copy no cookies at all? That would probably avoid this issue, at the cost of forcing the user to log in one extra time. Alternatively, we could take a heuristic approach and copy over cookies from the same second-level domain (anything from google.com), but that seems a bit strange because we normally treat sites with different domains as completely unrelated. > I'm not sure, but aren't the protocols, domains, and ports equal here and > only the host names are different? The domain is the hostname (hangouts.google.com vs. inbox.google.com). There is a way for the host site to allow a frame from a different domain to access it, using CORS, but clearly it didn't use that in this case. It's important because the parent domain might not necessarily trust the subdomain (e.g. imagine a school website where each department gets its own subdomain).
This is an interesting problem, so I've asked for suggestions on our mailing list: https://mail.gnome.org/archives/epiphany-list/2016-September/msg00004.html
I don't have an authoritative answer but I'd lean towards the "copy no cookies" way, too. That will work for sure and result in the minimum number of cookies.
Created attachment 335765 [details] [review] web-app-utils: Do not copy cookies when creating new web app Speculative patch, are you able to test it?
Well, I've cloned the repo, applied the patch, installed jhbuild which seems to clone and build any public repository on the internets. Seems like this may take a while. I'll report back.
After building epiphany from scratch using jhbuild, it immediately crashes with: (epiphany:7361): GLib-GIO-ERROR **: Settings schema 'org.gnome.Epiphany.ui' does not contain a key named 'tabs-bar-position' zsh: trace trap (core dumped) ./epiphany
(In reply to Tassilo Horn from comment #11) > After building epiphany from scratch using jhbuild, it immediately crashes > with: > > (epiphany:7361): GLib-GIO-ERROR **: Settings schema 'org.gnome.Epiphany.ui' > does not contain a key named 'tabs-bar-position' > zsh: trace trap (core dumped) ./epiphany Hm, are you running it in jhbuild? You need to use 'jhbuild run epiphany'. It's picking up the settings schema that's installed on your system instead of the version installed in your jhbuild prefix.
Obviously, I didn't. When I run it in jhbuild, it works fine, that is, when creating a web app, there's no cookies.sql file in the profile directory initially.
Attachment 335765 [details] pushed as 7a612ec - web-app-utils: Do not copy cookies when creating new web app