Opened 10 years ago

Closed 9 years ago

Last modified 20 months ago

#2910 closed defect (duplicate)

Popups handling in the web activity

Reported by: marco Owned by: erikos
Priority: high Milestone:
Component: browse-activity Version:
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


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

Change History (7)

comment:1 Changed 9 years ago by kimquirk

  • Milestone changed from Trial-3 to First Deployment, V1.0

comment:2 Changed 9 years ago by Eben

  • Owner changed from Eben to erikos

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:
  • Buttons: New Activity, Allow, Block

These are a first pass; I'm not sure how much description we really need. (eg. "The website is trying to create a popup for 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.

comment:3 Changed 9 years ago by Eben

  • Component changed from interface-design to web browser


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.

comment:4 Changed 9 years ago by marco

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:5 Changed 9 years ago by kimquirk

  • Priority changed from normal to high
  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:6 Changed 9 years ago by marco

  • Resolution set to duplicate
  • Status changed from reopened to closed

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

comment:7 Changed 20 months ago by Quozl

  • Milestone Update.1 deleted

Milestone Update.1 deleted

Note: See TracTickets for help on using tickets.