Popups handling in the web activity

[marco]

We need a spec of the wanted behavior for popups in the browser. There are several tickets opened about particular expects but I feel like we need to clarify the big picture here, and then verify/address the issues. Making it Trial-3 since there are Trial-3 bugs depending on it (#2594 for example).

[Eben]

The new design for popups employs the non-modal alerts in ticket #2822. When a popup occurs, an alert dialog will appear indicating the following:

• Title: Popup Window
• Description: www.popupcreator.com
• Buttons: New Activity, Allow, Block

These are a first pass; I'm not sure how much description we really need. (eg. "The website www.popupcreator.com is trying to create a popup for www.thepopup.com. Would you like to allow this?") I'd really like to err on the side of succinctness for now.

The idea behind the buttons is as follows: Block, of course, will simply do nothing with the URL. This will be the default option, and when we eventually have timeouts on non-modal alerts, this will allow one to continue browsing without having to pay attention to popups at all. The Allow button will simply load the target of the popup within the current window, as though it were a normal link. It will fall into the navigation stack like normal, so that pressing back will return to the page that invoked the popup. New Activity will, as it states, create a separate Browse instance containing the target of the popup link, as is the current behavior. I'm not sure we actually need this last one, but it does seem like a possibility.

[Eben]

Update:

After an extremely length discussion on IRC, Marco and I have come back around to a much much simpler design that was, I believe, our original hope for handling this case.

• unrequested popups (ie those which aren't called from an href tag) will simply be blocked.
• requested popups of all kinds will simply be treated as normal links, with the resulting page loaded into the same window as the parent such that pressing the back button will return to the parent page. There won't be support for side-by-side parent-child windows.

With regard to the latter, I personally think that their presence on the web is extremely small, and in most cases outdated (I've never personally seen a site that used this for anything other than to close the parent upon closing the child.) More importantly, we've decided that maintaining our activity model (which just happens to be the simplest to implement) is, at this point, more valuable and much easier than trying to accommodate the outliers. If through actual use in the field we find that use cases arise which require such functionality, we will re-examine the possible options and implement something more complex for handling them.

[marco]

It should be fixed. There are so many different types of popups that we will need some good testing here to make sure we handle all of them correctly. (Comment 3 explain the requirements).

[kimquirk]

Reopening as there are a number of pop ups that don't work in 650, the ship2 build. A customer alerted us to this one.

Specifically, go to about:config and try to change a setting. You can right click on a setting (such as network.proxy.type), and click 'modify', but you don't get the dropdown, popup, that will allow you to modify this setting.

[marco]

The about:config one is tracked by #5487. If you have reports of popups on web pages not working please open a separate ticket (note that unrequested popups are blocked by design, though).