Chrome seems to have two types of gesture token consumption behavior! |
|||||||
Issue descriptionFullscreen requests seem to consume UserGestureTokens in an erratic way, specially when "mixed" with popups: - A full-screen request prevents future full-screens w/o any warning, but can't prevent one popup. This is like a soft consumptions. - A popups prevents both full-screen & popup in future, with a console warning. Action legend: FR=full-screen-request, xx=manual full-screen exit, P=popup request Outcome legend: Y=granted, W=denied with "no gesture" warning, N=denied silently Observed action/outcome sequences: FR, xx, FR, FR => Y, -, N, N FR, xx, P, FR => Y, -, Y, W FR, P, FR, => Y, Y, W P, FR, FR => Y, W, W Repro: http://output.jsbin.com/lulode This is terrible, we need to fix it. Codewise still not clear why this is happening.
,
Jun 8 2017
I now suspect that this consumption type split is a result of the two consumption "level" we have today: we allow consumption through both UserGestureIndicator::ConsumeUserGesture() and UserGestureToken::ConsumeGesture() even though UGI contains UGTs! This is a messy API (assuming the design is somehow sane), very easy to get misused.
,
Aug 3 2017
,
Aug 14 2017
,
Sep 12 2017
,
Oct 5 2017
jochen@chromium.org explained this behavior to me: Fullscreen API relies on UserGestureIndicators but doesn't actually consume the current token. Popups do consume tokens. So we have token based APIs of two kinds: consuming and non-consuming. Luckily we have few on the consuming side: popups and WebUSB/WebBluetooth device request---I think that's it.
,
Nov 1 2017
,
Jun 14 2018
We are discussing the non-consuming behavior of fullscreen in Issue 852645. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by mustaq@chromium.org
, Jun 5 2017Labels: Hotlist-Input-Dev