Bug 114021 - Adopt consumable user gestures
Summary: Adopt consumable user gestures
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 114379
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-05 04:17 PDT by jochen
Modified: 2013-07-01 13:01 PDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jochen 2013-04-05 04:17:26 PDT
Chromium was the only port (afaik) that used consumable user gestures. Should we rip out the code that counts user gestures and makes them consumable? There's a security reason we introduced them which might make it appealing to WK2 based ports to keep them around (happy to give more details)
Comment 1 Alexey Proskuryakov 2013-04-05 14:36:44 PDT
The security concern doesn't appear to apply to other ports currently, but the behavior seems reasonable anyway - allowing a page to open tons of windows in response to a single click does not make sense to me.
Comment 2 Geoffrey Garen 2013-04-05 14:42:00 PDT
> the behavior seems reasonable anyway - allowing a page to open tons of windows in response to a single click does not make sense to me.

+1
Comment 3 Darin Adler 2013-04-12 17:04:50 PDT
Yes, I agree this is worth pursuing.
Comment 4 Maciej Stachowiak 2013-04-12 18:18:54 PDT
It may be tricky to get the rule right in the face of multiple user-gesture-restricted behaviors. For example, fullscreen API has a user gesture limitation. Should a single user gesture be able to go fullscreen once and open one window, or only one of these? The decision may be even more subtle on platforms like iOS that require user gestures for more things, such as playing media.

That being said, it does seem right to me that a single click should not be able to spam windows.
Comment 5 Brady Eidson 2013-04-12 22:03:03 PDT
I'd wager we'll eventually hear reports of intranet sites/tools broken by this, but agree that the tradeoff is probably worth it.
Comment 6 jochen 2013-04-15 04:13:42 PDT
(In reply to comment #4)
> It may be tricky to get the rule right in the face of multiple user-gesture-restricted behaviors. For example, fullscreen API has a user gesture limitation. Should a single user gesture be able to go fullscreen once and open one window, or only one of these? The decision may be even more subtle on platforms like iOS that require user gestures for more things, such as playing media.

When we designed this feature, we decided to only restrict creating new windows, i.e. an app can go fullscreen, lock the mouse, and open a new window. However, as soon as it opens the window, the user gesture is consumed, so it can't go fullscreen, open a new window, and lock the mouse.

> 
> That being said, it does seem right to me that a single click should not be able to spam windows.
Comment 7 jochen 2013-04-15 04:20:45 PDT
(In reply to comment #5)
> I'd wager we'll eventually hear reports of intranet sites/tools broken by this, but agree that the tradeoff is probably worth it.

So far, I got two reports: Our chrome experiment "The Wilderness Downtown" broke. It now tests whether the popup blocker is active, and if yes, shows a notification asking the user to disable the popup blocker for this site. And it broke pinboard's feature to restore multiple saved tabs which also requires the user to disable the popup blocker for that site.
Comment 8 Alexey Proskuryakov 2013-04-15 09:15:34 PDT
Some airline ticket search engines open multiple windows from a single click - e.g. skyscanner.com opens three. So, the number of allowed windows should be higher than one.
Comment 9 jochen 2013-04-15 11:13:19 PDT
(In reply to comment #8)
> Some airline ticket search engines open multiple windows from a single click - e.g. skyscanner.com opens three. So, the number of allowed windows should be higher than one.

Now that you mention it, I also came across a hotel meta search site that would just open popups with your search in a ton of other hotel search engines. I guess the behave we decide for depends on the goal:

To create a pop-under, you need to be able to open two sites, so to block pop-unders we need a limit of one.

To limit the amount of annoyance a webpage can cause, we can pick whatever number of windows we deem acceptable.

Thinking about it, to block pop unders, it would also be enough to limit windows to one kind, i.e. either a pop-up or a new tab.

A pop-under is usually created by first creating a pop-up, then opening a new tab in the original window (which raises the original window and turns the pop-up into a pop-under) and then closing the tab again. By only allowing one kind of new windows per user gesture, at least this scheme to create pop-unders also doesn't work.
Comment 10 Maciej Stachowiak 2013-04-15 15:19:21 PDT
Pop-unders (if I understand correctly) are generally created by first opening a window, and then calling window.blur on the newly created window or window.focus on a different window to ensure that the new window is behind the frontmost window (or tab). 

If the goal is to prevent pop-unders, then perhaps instead of restricting window open, we should restrict changes to the stacking order for newly created windows. This would turn pop-unders into pop-ups, so at least users would know which site caused the problem. I am not sure if that would break any of the mentioned sites.
Comment 11 jochen 2013-04-16 01:07:15 PDT
(In reply to comment #10)
> Pop-unders (if I understand correctly) are generally created by first opening a window, and then calling window.blur on the newly created window or window.focus on a different window to ensure that the new window is behind the frontmost window (or tab). 
> 
> If the goal is to prevent pop-unders, then perhaps instead of restricting window open, we should restrict changes to the stacking order for newly created windows. This would turn pop-unders into pop-ups, so at least users would know which site caused the problem. I am not sure if that would break any of the mentioned sites.

I changed that a while ago. window.blur() is now essentially a no-op, and window.focus() is very restricted (you can only focus a window you have opened when running within the context of the opening window). This matches Firefox' behavior.
Comment 12 Maciej Stachowiak 2013-04-16 02:22:36 PDT
(In reply to comment #11)

> 
> I changed that a while ago. window.blur() is now essentially a no-op, and window.focus() is very restricted (you can only focus a window you have opened when running within the context of the opening window). This matches Firefox' behavior.

Doesn't this render pop-under impossible then? Maybe I don't know what you mean by pop-under.
Comment 13 jochen 2013-04-16 02:25:02 PDT
(In reply to comment #12)
> (In reply to comment #11)
> 
> > 
> > I changed that a while ago. window.blur() is now essentially a no-op, and window.focus() is very restricted (you can only focus a window you have opened when running within the context of the opening window). This matches Firefox' behavior.
> 
> Doesn't this render pop-under impossible then? Maybe I don't know what you mean by pop-under.

No, you can still do this:

window.open("popup.html", "mypopup", "width=100,height=100");
window.open("about:blank").close();

the second window.open will create a new tab, so it focuses the original window again, thus turning the popup into a popunder
Comment 14 jochen 2013-05-10 07:00:08 PDT
I modified the NavigationScheduler to correctly track consumable user gestures in blink. I'd be happy to also change that in webkit, however, if no port uses this code, we can't run tests, and so I fear this will bit rot soon, and it would be better to rip out the code.

wdyt?