New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 901069 link

Starred by 2 users
Status: Fixed
Owner:
shivanisha@chromium.org
Closed: Nov 15
Cc:
█ johnpallett@chromium.org
mustaq@chromium.org
creis@chromium.org
shivanisha@chromium.org
mlamouri@chromium.org
alex...@chromium.org
powerb@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

FrameTreeNode does not reset sticky user gesture bit correctly

Project Member Reported by shivanisha@chromium.org, Nov 1 
Create a local file a.html:
!DOCTYPE html>
<meta charset="utf-8">
<!-- DO NOT SUBMIT: Fix Page Title. Missing tags? http://go/optional-html -->
<title>Page A: Users expect me to be the back target</title>
<html>
<body>
<a href="http://localhost:8000/redirect/b.html">Take me to page B with same eTLD+1</a>
<a href="https://cr.kungfoo.net/history_hijack/b.html">Take me to page B with different eTLD+1</a>
</body>
</html>

Run python -m SimpleHTTPServer 8000 in the directory where a.html is created

In the browser, run: 
http://localhost:8000/a.html

Click on the link "Take me to page B with different eTLD+1"

On going to b.html, it does a redirect to c.html
In both navigations to b and c the sticky user gesture bit is set when checked in NavigationControllerImpl::RendererDidNavigateToNewPage. The value being checked is rfh->frame_tree_node()->HasBeenActivated()

Since a.html and b.html are different eTLD+1, navigation to b and c should not have the sticky user gesture bits set.

Looks like FrameTreeNode does not have the resetting of the bits even when the RenderFrameHost changes, as is happening in this case.

Comment 1 by mustaq@chromium.org, Nov 1

Labels: -Pri-2 UserActivation Pri-3
I think renderer has the correct state because otherwise we would see many autoplay issues;  shivanisha confirmed this through https://codepen.io/mustaqahmed/full/pQzvzY/ (for this tester, we need to enable experimental features).

Dropping the priority since this is not exposed.

The only explanation I have is that when a renderer sets its state after a reload, it doesn't notify the browser.

Comment 2 by mustaq@chromium.org, Nov 6

Owner: shivanisha@chromium.org

Comment 3 by shivanisha@chromium.org, Nov 12

Status: Started (was: Available)
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 15 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd

commit c4f56158b3c305e28ce9af4c27ed13c1c30d32fd
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Thu Nov 15 15:58:39 2018

Clear User Activation bits for main frames when new document is installed

This is already being done in the renderer process during InstallNewDocument.
This change will do the clearing in the browser process FrameTreeNode and in
the RemoteFrame.

Test: content_browsertests --gtest_filter=*ClearUserActivationForNewDocument*
Bug:  901069 
Change-Id: Ia11aa078ffd9376565893264a5b6ce4257f63908
Reviewed-on: https://chromium-review.googlesource.com/c/1320517
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608381}
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/content/browser/frame_host/frame_tree_browsertest.cc
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/content/browser/frame_host/frame_tree_node.cc
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/content/browser/frame_host/frame_tree_node.h
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/third_party/blink/public/common/frame/user_activation_update_type.h
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/third_party/blink/renderer/core/exported/web_remote_frame_impl.cc
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/third_party/blink/renderer/core/frame/frame.cc
[modify] https://crrev.com/c4f56158b3c305e28ce9af4c27ed13c1c30d32fd/third_party/blink/renderer/core/frame/frame.h

Comment 5 by shivanisha@chromium.org, Nov 15

Status: Fixed (was: Started)

Comment 6 by mustaq@chromium.org, Nov 27

Cc: johnpallett@chromium.org powerb@chromium.org alex...@chromium.org shivanisha@chromium.org creis@chromium.org
 Issue 891792  has been merged into this issue.
►

Sign in to add a comment