Weird behavior when navigating away from request_ticket_v1.html

[cesium12]

After the popup opens, if I type certain URLs in the address bar (including https://webathena.scripts.mit.edu, https://scripts.mit.edu, https://mit.edu, https://linerva.mit.edu) but not others (including http://scripts.mit.edu, http://mit.edu, https://google.com, http://webathena.scripts.mit.edu [even though that redirects to https://]), the popup closes as soon as the page starts loading. Otherwise, it stays open, but iff I navigate back to request_ticket_v1.html (via history or url bar) and then go to one of the first set, it closes.

[davidben]

Ugh, I bet this is a quirk of when Chrome does and doesn't keep pages in the same process (unit of similar-origin related browsing contexts... https://**.mit.edu are all similar-origin). This has an effect on things like window.name namespaces, though I'd be kinda disturbed if WinChan used that. There's probably something else going on. I read through the code before, but it'd be good to do it again.

I guess this is why BrowserID does a popup? So you can't navigate it away... I imagine Chrome will also consistly enter popup mode if we actually pass in a window_features to WinChan.open.

[cesium12]

Yeah, I'm pretty sure we want to make it always a popup with navigation disabled and such.

[davidben]

We may need to experiment a bit to see exactly what browsers do. The features argument isn't really all that standard between browsers. The spec officially says to just ignore it, though that doesn't necessarily mean much. (I imagine the reasoning is that it's very dependent on your browser's UI and probably not incredibly interoperable anyway. The defaults in WinChan already acted different between Chrome and Firefox. Though that could easily be some UA sniffing.) Also we don't really want to hide the location bar, although it shouldn't be possible to hide that these days.

It may be worth investigating if we can prevent it from closing in the first place, in addition from tailoring the exact shade of popup. That seems a pretty poor choice on Mozilla's part. I could easily imagine the distinction between popup and window is less clear on a mobile browser. Maybe popups are still navigable.