mstoltz asked that I bring this up in the newsgroup for opinions... This is bug 159036
> It has been discussed in numerous bugs (bug 126224, bug 132031 and
> dups) that the method we use to determine "unrequested" windows is
> not sufficient. (Sites can use onload event handlers in images for
> example.)
>
> This bug calls for the creation of a "Whitelist" of valid, requested
> windows. Instead of devoting man-hours to constantly countering every
> move a developer makes to get a pop-up, we simply enumerate what *is*
> a valid window and keep our work to a minimum.
>
> If done properly, this should not result in any significantly higher
> number of false positives, and in fact may fix some of the issues at
> hand currently like clicking a valid popup-creating link during the
> page load which is caught as invalid.
>
> While the actual complete whitelist should undergoe discussion, the
> following is my list of "requested" windows:
>
> 1. Opened from the interface (in new window, middle click, File >
> New, Accel-N, etc.) -- these are already immune and don't need to be
> worried about. 2. Opened via an onClick, onDblClick, onMouseDown,
> onMouseUp, onKeyPress, onKeyDown, onKeyUp, onSubmit?(debatable). 3.
> Opened via a javascript: URL of a clicked link. 4. Opened via a
> function called from one of these functions. (anywhere down the line)
>
>
> The onSubmit is not necessarily a user-activated event, but is often
> used as such. (I would say onFocus too, but the idea of someone
> *requesting* a popup window via tabbing into a field seems
> far-fetched.) The problem is that a malicious web developer could
> call a submit() routine on a form with no visible elements and no
> href and effectively get around the popup blocking. (This is similar
> to the case in bug 152007 -- there an onload calls a submit which
> submits to a new 'target' thereby opening a new window... tricky and
> evil.)
>
> Rginda posed a question to this list in bug 126224 which I'll answer
> here to keep the bugs on-topic.
>
>>> what about |document.location = "javascript:void
>>> window.open('foo.html');";|?
>
> I would posit that a javascript: url would only have the rights to
> open a new window if originally activated via a user action (click,
> keypress, etc.) If this line was present in a function which had been
> called via a valid event handler (2) or a javascript: link (3) or a
> function called from such (4) *then* it would be valid.
>
> -----------------------
>
> This will require being ale to determine what was the original cause
> of the activation of a given javascript function. I am not enough of
> a javascript guru to know whether this is possible without (as rginda
> suggests) a flag which is kept through the life of the function (and
> its children) which validates whether the calling method was on our
> list.
>
> The above method would really only work in
> GlobalWindowImpl::HandleDOMEvent and therefore would need to be
> worked out for javascript: URLs.
>
> Thats it for now. Other issues which may need to be discused (so I
> don't forget them down the road...) 1. A named target in a link or
> form submission -- is it a request? (didn't we have a pref for this
> at some point? Should it only be a request if called via a user
> action (i.e. stopping bug 152007) 2. Accessibility people may need to
> look at the list of event handlers. (I added keyboard handlers for
> this reason, but there may be others I'm not considering. -- focus)
smime.p7s
Description: S/MIME Cryptographic Signature
