Cross origin navigations lose the user_gesture |
|||||
Issue descriptionFrom 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.
,
Sep 21 2017
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).
,
Sep 21 2017
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.
,
Sep 21 2017
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.
,
Sep 21 2017
<+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]>
,
Sep 22 2017
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.
,
Sep 28 2017
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.
,
Sep 29 2017
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).
,
Sep 29 2017
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 |
|||||
Comment 1 by csharrison@chromium.org
, Sep 21 2017