jm.acuna73@ Could you please provide test file for the test cases mentioned in Comment #0 which helps us in easy repro of the issue.

Thanks!

Thank you for providing more feedback. Adding requester "jbanavatu@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Example B with the chrome:// URL is working as intended.  Web pages aren't allowed to navigate to chrome:// URLs, so that window.open call will fail whether there's a subsequent download or not, leaving no new tab.

Example A seems to show some interesting behavior differences, though.  I think it's specific to the PlzNavigate field trial (--enable-browser-side-navigation, or c68ab9a3-6edc92c7 in the Variations of about:version).  This trial isn't enabled on M58.

Specifically, the download doesn't work and the new tab stays open in the default case, and the download works and closes the new tab in the PlzNavigate case.

Neither of those behaviors seem correct to me at first glance.  I think I would expect the download to work and the new tab to stay open (perhaps unless the tab's initial URL was about:blank).

I wonder why the download isn't working in the non-PlzNavigate case.  We may not need to worry about that, though, since PlzNavigate will be enabled by default soon.

However, in the PlzNavigate case, we should prevent the tab from closing if there's already a real page committed in it.  clamy@, can you or arthursonzogni@ take a look?

creis@: I get the opposite results in example A:
*     PlzNavigate: the new tab stays open and no download.
* non-PlzNavigate: the new tab is closed and there is a download.

At a first glance, It looks like there is two concurrent navigations and one of theme is canceled/replaced in both cases. The second navigation is canceled with PlzNavigate and the first one without PlzNavigate.
Looking at this: https://docs.google.com/document/d/1jK50LDDHodStsXlTb6k_cFlIBochkaNWcSOI5M-sVLo/edit#heading=h.ka8wthjayrzf

```
With PlzNavigate we move to a much simpler model where any navigation started by the user cancels a current navigation that is waiting for a response, which should lead to more intuitive results. Conversely, a non-user initiated navigation will not proceed if there is an ongoing user-initiated navigation in the FrameTreeNode. For more details, see the design doc on navigation cancellation.
```

Ironically, navigations triggered with the OpenURL will use the browser-initiated path. Maybe it corresponds to what is called a "user initiated" navigation. Then the second navigation (the download) will not proceed? I will investigate...

I investigated, indeed the second navigation (the download) is canceled.
Here is a few print I put to understand why:
```
NavigatorImpl::OnBeginNavigation(url = https://www.google.com/)
   begin_params.has_user_gesture = 1
   ongoing_navigation_request = 0

NavigatorImpl::OnBeginNavigation(url = http://d.7-zip.org/a/7z1700.exe)
   begin_params.has_user_gesture = 0
   ongoing_navigation_request = 1
   ongoing_navigation_request->browser_initiated() = 0
   ongoing_navigation_request->begin_params().has_user_gesture = 1
   => New navigation is cancelled
```

What surprise me is that |begin_params.has_user_gesture| is true for the first navigation and false for the second one. It explains why the second navigation doesn't replace the first one.

I took a look at UserGestureToken and UserGestureIndicator. I think one UserGestureToken has been created (on mouse click) and is used for the first navigation. Then no more additional navigations are considered to be "user-initiated".

It looks like everything is working as intended. However, It implies that only the first navigation occurs. Are we happy with it? What do you think we should do?

As for the rational behind not allowing navigations with no user gesture gesture to cancel navigations with user gesture, this prevents a malicious page from constantly issuing navigation requests through javascript that would prevent the user from navigating away from it by canceling any navigation the user initiate.

#5: That is not what I'm observing on Windows Canary 61.0.3117.0.  With PlzNavigate enabled, the download works and the tab closes.  With PlzNavigate disabled, the new tab opens to Google and the download never happens.

In a debug build on Linux (built from revision 476068), PlzNavigate hits multiple DCHECKs:
1) NavigatorImpl::OnBeforeUnloadACK
  DCHECK_EQ(NavigationRequest::WAITING_FOR_RENDERER_RESPONSE,
            navigation_request->state());
2) NavigationRequest::BeginNavigation() {
  DCHECK(!loader_);
  DCHECK(state_ == NOT_STARTED || state_ == WAITING_FOR_RENDERER_RESPONSE);
If I comment out all three of those, it downloads the file and closes the tab (same as Windows Canary).

If I run the debug Linux build without PlzNavigate, the new tab opens to Google and the download never happens (same as Windows Canary).

Given that we seem to be observing opposite results (and that we're hitting DCHECK failures in PlzNavigate), I don't think this is working as intended.  :)

Can you take a closer look to see what might be causing the difference?  I'd suggest a debug build on trunk, so that field trials don't apply and DCHECKs are present.

(In the end, I'm ok if the answer is that an intentional change to cancellation behavior is visible here, but it sounds like we're observing different and thus unexplained things.)

Nick points out that it might be a race with the navigations actually succeeding.  For example, if the latency for the download server is high for you, maybe the Google page is committing first and thus altering the behavior?  You might try with different test URLs.

I tried Linux Canary 61.0.3117. I still get the same results.
PlzNavigate => google.com | non-PlzNavigate => download.

Maybe you get different result due to a race but in this case it means that www.google.com is fast enough to commit, then the download navigation could also start without being canceled. At the end you would have the new tab page AND the download.

I tried the Linux Debug(446142,476615) version. I don't hit any DCHECK and still get the same results... :(

Bizarre.  :)  I'm trying to make some progress understanding the differences.  Here's a variation, and I'm curious how it behaves for you.

data:text/html,<script>function go(){open('https://csreis.github.io','_blank').location.replace('http://csreis.github.io/tests/test-download.zip');}</script><input type="button" onclick="go()" value="test"/>

vs

data:text/html,<script>function go(){open('https://www.google.com','_blank').location.replace('http://csreis.github.io/tests/test-download.zip');}</script><input type="button" onclick="go()" value="test"/>

In the first case (popup to csreis.github.io), I see what you describe.  Download and closed tab in default mode, but popup stays open and no download in PlzNav.

In the second case (popup to google.com), I see what I described before.  Popup stays open and no download in default mode, but download and closed tab in PlzNav.

Does that affect your observations at all?  I wonder if having Google as the default search provider (and thus forcing a process swap) is involved.

On my side, I still get the same results with (Linux, {Debug, Release}, revision 477295)
Url 1:
   PlzNav: new tab https://csreis.github.io/
   OldNav: download test-download.zip
Url 2:
   PlzNav: new tab https://google.[...]
   OldNav: download test-download.zip

Still no DCHECK hit.
The only way for me to get the download with PlzNavigate is when the first URL is a data-url. 

@clamy made a CL that allow document-initiated navigation with no user-gesture to cancel document-initiated navigation with an user-gesture:
https://chromium-review.googlesource.com/c/chromium/src/+/616642
It fixed  https://crbug.com/755507  and also this issue. Both are very close.

I checked that when I click on:
data:text/html,<script>function go(){open('https://www.google.com','_blank').location.replace('http://d.7-zip.org/a/7z1700.exe');}</script><input type="button" onclick="go()" value="test"/>
it downloads the executable file and closes the tab.