[webkit-dev] restricting the number of new windows created in response to a user gesture

Brady Eidson beidson at apple.com
Fri Apr 12 13:40:46 PDT 2013


On Apr 12, 2013, at 5:05 AM, Jochen Eisinger <jochen at chromium.org> wrote:

> Hi,
> 
> currently, WebKit allows for an arbitrary number of new windows to be created in response to a single user gesture. This is "used" for example to create pop-unders.
> 
> In order to restrict the number of new windows to one per user gesture, a port needs to invoke UserGestureIndicator::consumeUserGesture() in it's ChromeClient::createWindow method.
> 
> In https://bugs.webkit.org/show_bug.cgi?id=114379 I add this for WK2 and for WK1 mac/win.
> 
> Are other ports interested in this behavior? If not, I'd just skip the corresponding tests.

I'm not sure it's the right move to force this on any port.  Some ports might be interested, for example, in not breaking legitimate intranet tools that use multiple pop-ups/unders.

> There are some gotchas: e.g. if your port is using out of process plugins, and the plugin wants to react to a user gesture, you're probably storing whether WebKit is processing a user gesture before calling out to the plugin, and restore a UserGestureIndicator once the plugin replies. To make sure a plugin cannot use this to generate additional user gestures (after the original user gesture was already consumed), you should store the UserGestureIndicator::currentToken() and use that to create the UserGestureIndicator (it's basically a ref-counted integer of how many gestures are left to consume).

Skipping tests is one thing.  It's definitely not okay to break functionality in a port like this.

~Brady

> 
> best
> -jochen
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/58cead2b/attachment.html>


More information about the webkit-dev mailing list