On Fri, Apr 12, 2013 at 10:40 PM, Brady Eidson <beid...@apple.com> wrote:
> > On Apr 12, 2013, at 5:05 AM, Jochen Eisinger <joc...@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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
