GNOME Bugzilla – Bug 794352
"Open Gmail" links does nothing after entering Sync credentials
Last modified: 2018-05-06 21:55:33 UTC
After first logging into Sync on 3.26.6, the button to open my gmail and confirm the new sign-in appears to do nothing.
It's hard to imagine how this could be related to Sync... does GMail start working when you sign out of sync? Can you reproduce if you disable adblock? Can you reproduce in a private profile ('epiphany -p')? In MiniBrowser? Any errors in the web inspector?
It's quite easy to imagine, but it's not a question of the GMail site working or not. The very first time you sign-in to sync, you get a confirmation email from Firefox requesting permission to access from epiphany, and the sync code pops up a dialog with a button "Open GMail", but clicking that button does nothing. Now that I've authenticated with Firefox, I don't know how to force another 2fa request and trigger that code path again.
(In reply to Charlie Turner from comment #2) > It's quite easy to imagine, but it's not a question of the GMail site > working or not. The very first time you sign-in to sync, you get a > confirmation email from Firefox requesting permission to access from > epiphany, and the sync code pops up a dialog with a button "Open GMail", but > clicking that button does nothing. Sounds like Mozilla changed the login page. Drat, that's going to be "fun" to fix. I guess we could try loading the content in the preferences dialog's web view, but we really, really did not intend for this small web view to be displaying GMail content. This might be quite tricky. We might have to add a web extension, walk the DOM, and hide the open GMail button. I was thinking about how to find time to work on this, and it occurs to me that this would be a really good testcase for the new JSC GLib API. Carlos, what do you think?
Created attachment 371746 [details] [review] prefs-dialog: Account for open-webmail button click at Sync sign-in
Review of attachment 371746 [details] [review]: Oh wow, this was a lot easier than I expected. Excellent, thanks! ::: src/prefs-dialog.c @@ +565,3 @@ + script = + /* Handle sign-in messages from the FxA content server. */ + "function handleToChromeMessage(evt) {" This would be a good opportunity to rename evt to event, for better readability. @@ +579,3 @@ + " if (stage.addEventListener)" + " stage.addEventListener('click', handleOpenWebmailClick);" + " else if (stage.attachEvent)" I found this documentation for attachEvent: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/attachEvent "This is a proprietary Microsoft Internet Explorer alternative to the standard EventTarget.addEventListener() method." Remember this code is running in Epiphany, so we have a bit of an advantage over web developers in that we know we aren't Internet Explorer. So you should be able to remove this condition, right? Is it really needed for some reason?
(In reply to Michael Catanzaro from comment #5) > https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/attachEvent > > "This is a proprietary Microsoft Internet Explorer alternative to the > standard EventTarget.addEventListener() method." > > Remember this code is running in Epiphany, so we have a bit of an advantage > over web developers in that we know we aren't Internet Explorer. So you > should be able to remove this condition, right? Is it really needed for some > reason? Yup, you're right. I'll remove it.
Attachment 371746 [details] pushed as 083c9bc - prefs-dialog: Account for open-webmail button click at Sync sign-in