bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Closing Persona pop-up windows




Firefox for iOS
3 years ago
2 years ago


(Reporter: peterbe, Assigned: Nathanael Alcock, Mentored)



Firefox Tracking Flags

(fxios-v5.0 fixed, fxios-v6.0 fixed, fxios+)



(1 attachment)

48 bytes, text/x-github-pull-request
: review+
Details | Review | Splinter Review


3 years ago
Reproducible every time (Build #19)

* 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 

* Tab still open and it says "my@email.com 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
Comment hidden (obsolete)
Let's land it and see if it fixes this


3 years ago
Assignee: nobody → bmunar
Comment hidden (obsolete)
Comment hidden (obsolete)


3 years ago
Assignee: bmunar → nobody
James, do you have context here?
Flags: needinfo?(jhugman)
Flags: needinfo?(jhugman) → needinfo?(sarentz)
tracking-fxios: ? → ---
Flags: needinfo?(sarentz)
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(...);

Seems like a plausible cause to me, and we should support this usage regardless.
tracking-fxios: --- → ?
Rank: 4
tracking-fxios: ? → +
Mentor: bnicholson

Comment 11

2 years ago
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.


2 years ago
Assignee: nobody → nalcock

Comment 12

2 years ago
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+

Comment 15

2 years ago
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.