Browser-side activation notification alone can't solve postMessage timing problem |
||
Issue descriptionThis is re User Activation v2. We added a bit in old user gesture code to "carry" user gesture token status cross process: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/user_gesture_indicator.h?rcl=7c3a331ed75e2a7db08dbbcfc105467c6d030759&l=48 Since UAv2 doesn't need per-process tokens, we assumed that the bit won't be needed for UAv2, specially after we have moved UserActivation detection code to the browser process. dtapuska@ pointed out that with postMessages following their own Mojo channels, UAv2 can't guarantee that the postMessage recipient process have the activation bit "cache" updated in time unless we pass a "hint" bit with the postMessage. Consider this scenario: - We have frame A containing frame B in a separate process, user clicks on B, the the even handler in B sends a postMessage to A. - Upon receiving the user input, the browser sends activation updates to A through channel Br->A, to B through channel Br->B, and also sends the event to B through Br->B. - The second update reaches B first, and the event handler sends the postMessage through B->A channel. - B->A is also fast, so A gets the postMessage before the activation update. Suggested solution: - PostMessage would carry a "hint" on activation. - If the hint disagrees with the renderer's activation cache state, make a blocking call to browser.
,
Jun 11 2018
Yes - AFAIK cross-site postMessages always go through the browser (today FrameHostMsg_RouteMessageEvent is a legacy IPC going from renderer to browser process). I think in the future postMessages will have to keep going through the browser process - there are some security checks and ordering guarantees done by the browser process (see RenderFrameProxyHost::OnRouteMessageEvent) and these would have to be retained even after migrating to mojo.
,
Jun 11 2018
I agree with #2. Today, the browser process checks that the postMessage should go through (that it's to a frame in the same BrowsingInstance), sometimes creates a proxy for sender in the target process (<webview>), and also syncs visual properties (see issue 822958) before forwarding the postMessage. Sending postMessage directly from renderer to renderer is interesting to consider, since we'd solve the problem of increased browser process CPU burn for a continuous stream of postMessages, which we've seen in site isolation ( issue 799755 ). But given the above, I don't think we can easily skip going through the browser, at least not in all cases. Also, as lukasza@ mentioned on another thread, if the postMessage carries a user gesture, the browser process should try to verify that the sender actually has it. With UAv2, I think this can already be done via FrameTreeNode::user_activation_state_. |
||
►
Sign in to add a comment |
||
Comment 1 by mustaq@chromium.org
, Jun 11 2018