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

Issue 767322 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Cross origin navigations lose the user_gesture

Project Member Reported by csharrison@chromium.org, Sep 21 2017

Issue description

From printf-style logging on NavigationHandle in DidFinishNavigation, repro'd on:

data:text/html,<a href="https://www.google.com">google</a>

I noticed this does not happen for same-origin navs though.
 
Oh, I think this might be because in PlzNavigate, cross-site navs will end up being "browser initiated", which doesn't support user_gesture yet?
Cc: clamy@chromium.org jam@chromium.org nasko@chromium.org
FWIW, I cannot repro the problem with or without PlzNavigate.

Printf-logging:
    void WebContentsImpl::DidFinishNavigation(NavigationHandle* navigation_handle) {
      LOG(ERROR) << "; navigation_handle->HasUserGesture() = " << navigation_handle->HasUserGesture()
                 << "; navigation_handle->GetURL() = " << navigation_handle->GetURL();

I tried the repro at ~ToT (r502380) (and so with PlzNavigate on by default / after r502251):

$ out/gn/chrome --user-data-dir=$HOME/.chrome-adhoc-user-gest-plznav 'data:text/html,<a href="https://www.google.com">google</a>'
[121155:121155:0921/080257.369662:ERROR:web_contents_impl.cc(3741)] ; navigation_handle->HasUserGesture() = 0; navigation_handle->GetURL() = data:text/html,<a href="https://www.google.com">google</a>
[121155:121155:0921/080302.407527:ERROR:web_contents_impl.cc(3741)] ; navigation_handle->HasUserGesture() = 0; navigation_handle->GetURL() = https://www.google.com/

Similarily, I got no repro with PlzNavigate disabled:

$ out/gn/chrome --user-data-dir=$HOME/.chrome-adhoc-user-gest-plznav 'data:text/html,<a href="https://www.google.com">google</a>' --disable-browser-side-navigation
[121437:121437:0921/080343.627246:ERROR:web_contents_impl.cc(3741)] ; navigation_handle->HasUserGesture() = 0; navigation_handle->GetURL() = data:text/html,<a href="https://www.google.com">google</a>
[121437:121437:0921/080347.088081:ERROR:web_contents_impl.cc(3741)] ; navigation_handle->HasUserGesture() = 0; navigation_handle->GetURL() = https://www.google.com/


Maybe I misunderstood 1) where the printf logging is done or 2) the repro steps (I launch chrome at data:text/html,<a href="https://www.google.com">google</a>  and then I click the link).
To me it looks like you are reproing the issue, because HasUserGesture() is returning 0 even when you've clicked on the link, according to the logs you pasted.

Your (1) and (2) are correct.
Ooops - you're right.  I *was* reproing the lack of user gesture.

But I think #c2 does show that this is not a PlzNavigate-specific issue.
Cc: kenrb@chromium.org alex...@chromium.org
<+alexmos@ and kenrb@ who have worked on user gesture support for OOPIFs  [although AFAIK this was for subframes = this was different from this bug which talks about the main frame]>
I have a WIP Cl that does some plumbing from OpenURL -> NavigationRequest::CreateBrowserInitiated. This solves the immediate problem at least.

My guess is the change of behavior is having link clicks in the current tab go through OpenURL, which is probably intentional but it is pretty confusing, as a link click should not really create a "Browser initiated" nav IMO.

Comment 7 by nasko@chromium.org, Sep 28 2017

Cc: creis@chromium.org
Why do you believe link clicks result in OpenURL? That is a surprise to me, so it will be useful to understand. If you mean click plus a modifier (ctrl, shift, etc), then I can see it, but for regular link clicks we should be going through BeginNavigation IPCs to the browser (with PlzNavigate).

The cases that OpenURL is used are when we have window disposition or we know we need to do a cross-process navigation for renderer-initiated navigations. It isn't clear to me from the repro steps that a data: URL document will require us to go to the browser with regular simple click on the link.
You're right, that's my intuition as well. I saw this in a stack trace, but I can quickly verify again.

I was seeing the same behavior on a non data URL, but since it repro'd on the data URL I posted that instead (for simplicity).
Status: WontFix (was: Untriaged)
I am now having trouble reproducing this for anything other than data URLs, and most-visited tiles in the NTP. I think I may have saw those two cases and jumped to conclusions, though I have some memory of seeing it on other sites too...

I think it makes sense to WontFix, as data URLs and NTP are pretty much edge cases. Sorry for the noise.

Sign in to add a comment