Summary

  • Mozilla's March 2003 product news already treated pop-up blocking as a browser feature; its June 2003 Mozilla 1.4 announcement described improvements to it.
  • Internet Explorer 6 under Windows XP SP2 distinguished a window associated with a user's click from one triggered by page script, and placed blocked pop-ups under an Information Bar. Today's window.open() guidance requires a separate user gesture for each new window.

A web page knows how to ask for a new window. The awkward question is whether its visitor asked too. Mozilla's archived news from March 2003 lists pop-up blocking among the browser's existing features; its June announcement says Mozilla 1.4 improved that blocking. The March and June notices show a browser feature being refined in public. The browser had begun acting as a doorman between page script and a person's screen.

Microsoft's original Internet Explorer 6 deployment guide for Windows XP Service Pack 2 called the built-in blocker a first for Internet Explorer and put it beside a new Information Bar. Microsoft announced SP2's release to manufacturing on 6 August 2004. The rollout then moved through manufacturers, enterprises and consumers. The useful detail lies in how the blocker chose which door to open.

Microsoft's own explanation of IE6 SP2's user-initiation rule says the browser detected a click on a link or page element before the page created a pop-up. A window following that act received different treatment from one launched by script alone. Most requested pop-ups could proceed; an unrequested one could be caught by the Information Bar, where the visitor could choose to view it. The site still had a window.open() call. The browser wanted an invitation with it.

The invitation was a traceable event: someone clicked, and the page immediately asked for one more browsing context. Current Mozilla documentation for window.open() states the practical rule plainly: a pop-up should follow direct user input, and each call needs a separate gesture. A blocked call may return null. The page can check the result and keep its interface coherent instead of assuming the extra window opened.

The HTML Living Standard's user-activation model gives a click a short-lived invitation. Transient activation lasts only briefly; some gated APIs consume it. After consumption, another call needs another human action. The standard even accounts for nested frames, so a page cannot spend the same gesture repeatedly by passing it down a family tree of iframes. The browser accounts for the visitor's latest deliberate act before allowing a page to multiply windows.

The result was a new etiquette for web software. A legitimate extra window could be tied to the button that requested it. A page that opened several doors on its own had to meet a bouncer it did not employ. The pop-up blocker made window.open() a request with a provenance question attached: who knocked?