Please report any other irregularities here.
Reproducible every time (Build #19) STR * Go to a site that uses Persona. E.g. air.mozilla.org * Click Sign in * Fill in email & password etc. * Click sign in Expected results: * Tab to close Actual: * Tab still open and it says "firstname.lastname@example.org verified!\nSigning you in..." Just closing the tab works. The previous tab (where I clicked the Persona pop-up to start) will have reloaded and I'm signed in successfully.
Works in Safari. This might be bad for things like portals too. Ought to investigate.
tracking-fxios: --- → ?
I think this is related to: https://bugzilla.mozilla.org/show_bug.cgi?id=1172928
Let's land it and see if it fixes this
James, do you have context here?
As noted in bug 1172928 comment 12, it didn't fix this issue and I'm still seeing it today on Version 2.1 (2).
MattN suggested that Persona might be using window.close() from the parent, using the reference of the child window: var win = window.open(...); win.close(); Seems like a plausible cause to me, and we should support this usage regardless.
tracking-fxios: --- → ?
I'm not sure but the code may be one of the two window.close at https://github.com/mozilla/persona/blob/a76621d9f7f23da596d0c1865e2e8142eff21de0/resources/static/common/js/lib/winchan.js#L244-L272
I've identified the case in which, and why, this does not work: When you open a new window using window.open() with a URI that is considered cross-domain, some of the properties — including, crucially, the window.close method, become read-only. To hook into window.close, we try to overwrite it, but with a cross-domain window pair, the attempt is simply ignored, and so the custom code is never run. Essentially, we can't modify opened windows in any way. This makes listening for events on them difficult, but I'm going to see if I can find a way round the problem.
Created attachment 8765586 [details] [review] Pull request
Attachment #8765586 - Flags: review?(bnicholson)
Comment on attachment 8765586 [details] [review] Pull request As mentioned over IRC, let's try out the "new" iOS9 webViewDidClose callback in WebViewUIDelegate (not sure how we missed this one before!). I think your proxy hack could be a good alternative if webViewDidClose doesn't work as we expect.
Attachment #8765586 - Flags: review?(bnicholson) → feedback+
Comment on attachment 8765586 [details] [review] Pull request Looks great! Left a few minor comments in the PR, but looks good to land otherwise.
Attachment #8765586 - Flags: feedback+ → review+
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Low risk (and the BrowserHelper is disabled altogether for iOS 9+), so uplifting to v5.x since this bug can be annoying. v5.x: 7448fdc
status-fxios-v5.0: --- → fixed
status-fxios-v6.0: --- → fixed
You need to log in before you can comment on or make changes to this bug.