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

RESOLVED FIXED

Status

()

Firefox for iOS
Browser
RESOLVED FIXED
3 years ago
2 years ago

People

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

Tracking

unspecified
Other
iOS

Firefox Tracking Flags

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

Details

Attachments

(1 attachment)

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

Description

3 years ago
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 "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

Updated

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

Updated

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(...);
win.close();

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

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.
(Assignee)

Updated

2 years ago
Assignee: nobody → nalcock
(Assignee)

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+
(Assignee)

Comment 15

2 years ago
https://github.com/mozilla/firefox-ios/commit/e3940ee453a41c805be636319e562414402dc19d
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.