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

[Jochen Eisinger]

On Fri, Apr 12, 2013 at 10:40 PM, Brady Eidson <beidson at apple.com> wrote:

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

Right, that was my question: which ports are not interested, so I don't
enable it for them.



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

I guess the paragraph was unclear: it's not breaking functionality. The out
of process plugin code already has the logic to create a
UserGestureIndicator.

I tried to explain that by using a plugin, a website can work around the
restriction (which is already true now).


>
> ~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/dc7adadd/attachment.html>