marking as RBS, please change if required

I can duplicate this a little easier:

- open browser
- hit ^J to navigate to the download page
- hit ^!N to open incognito window
- hit ^J - correctly navigates to a new download page within incognito tab
- hit ^L and enter 'chrome://about' (or most any site) - will navigate there in incognito tab
- hit ^J again - it will switch over to the non-incognito copy instead of opening it

Still looking.

Peter,

Can you comment on which way we should go on this? Here's the story:

If you hit ^J at a NTP *and* there is no open download page in the current window, Navigate() is passed a disposition of CURRENT_TAB and it navigates to the download page without switching for any other copy.

But if you're not at the NTP, *or* there is a download page somewhere in the *same* window, it passes a disposition of SINGLETON_TAB. In the latter case, it switches to this tab, but in the former, it searches for a download page and (now) finds one in the non-incognito window.

It didn't used to do this. SINGLETON_TAB (apparently) meant "in this window", not "any window" (I'm guessing to punt security issues.)

So...

- declare WAI ?
- hunt upstream for whatever is fiddling with the disposition so that all case are equal ? Will take (me) some time. Note that we also need to cause it to trigger a refresh to pick up the new download.
- separate singleton's behavior to only search this window? Should be trivial to do in existing loop.

I suspect the latter, but maybe you know of some caveats. IIRC this would then open a brand new copy of settings within an incognito window. I assume this was the old behavior? If not, maybe this upstream code is playing more games. Note that this might also fix 807171 (opening settings from hangouts window) but I can't guarantee.

AFAICT, the problem here is that we are using SINGLETON_TAB to mean different things regarding incognito.

Something like History isn't meaningful in incognito, so we want SINGLETON_TAB to force a profile switch to the regular profile.  But Downloads _are_ meaningful in incognito, so we want SINGLETON_TAB to search only within the current profile and not cross the incognito boundary (either direction).

AIUI, the old code didn't really handle this correctly either, it just fell down in different ways.

I suspect what we really want is for SINGLETON_TAB to always search only the current profile, respecting incognito state (just like SWITCH_TO_TAB); and then for users to specify which profile they want, whether that's the "current profile" or the "base of the current profile" (i.e. switch to normal if in incognito).  Then people opening History or Settings should pass "base profile", and Downloads should pass "current profile".

Isn't this on 65 too? Can you verify and update the bug?

Able to reproduce the issue on 65.0.3325.31 as well on Windows and Mac aswell. 

dbote@ can you please rebisect the bug again and provide the right bisect range. 

Hi, w.r.t. comment #8

Re-bisected again on different machine and getting the same bisect range.

CL: https://chromium.googlesource.com/chromium/src/+log/c5ef96cb52d3c997b6b4c45bb50930042490882d..bc51d227d7879a44b0b5fabba7be1b58db1f1375

Thank You!

An update w.r.t to comment #8 
Rechecked in M65 builds and observed that: 
Its broken in M65 branch builds Good build #65.0.3325.0 and Bad Build #65.0.3325.18.
And its working fine in M66 from build#66.0.3326.0 to build#66.0.3328.0 and again broken in M66 #66.0.3329.0(Bad Build).

Due to same base point(Revision), we are unable to run the bisect hence providing the manual CL:

CHANGE-LOG:
https://chromium.googlesource.com/chromium/src/+log/bc084a8b5afa3744a74927344e304c02ae54189f..8537a0b30e659eefb087ec25b97a1a7f61e2d672?pretty=fuller&n=10000.

Thanks!

IMO this is not RBS.  You *can* see the downloading files in an incognito window, for example if you don't already have a non-incognito download page open.  The bug occurs only when you try to open both at once in this particular order.  That set of actions seems rare.

We should still fix, but I don't think a fix needs to merged to M65.

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

commit cc983247c218b60efbf1de5fe3e1f6f12dcaf160
Author: Kevin Bailey <krb@chromium.org>
Date: Sat Feb 03 18:42:24 2018

[browser nav] Have singleton disposition behave differently from switch

We had SINGLETON_TAB and SWITCH_TO_TAB dispositions sharing a code
path. This change separates them such that singletons only search in
the current window for a tab, and fall-back to new-foreground-tab
instead of current-tab.

Bug:  807171 ,  807550 
Change-Id: I0fb3bb75806269df0916359d4c89246640241660
Reviewed-on: https://chromium-review.googlesource.com/896745
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Kevin Bailey <krb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534279}
[modify] https://crrev.com/cc983247c218b60efbf1de5fe3e1f6f12dcaf160/chrome/browser/ui/browser_navigator.cc
[modify] https://crrev.com/cc983247c218b60efbf1de5fe3e1f6f12dcaf160/chrome/browser/ui/browser_navigator_browsertest.cc

Just to Update:

Rechecked above issue on Windows (7,8,8.1,10),Linux (14.04 LTS) using latest canary build #66.0.3340.0 and it is fixed.

Kindly refer attached video for the reference.

Thank you.

Deleted: Issue_Fix.mp4 895 KB

	Issue_Fix.mp4 895 KB View Download

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

commit d7e23eff72fe2872f607e27730c41d90ca68cdec
Author: Kevin Bailey <krb@chromium.org>
Date: Mon Feb 05 18:55:24 2018

[browser nav] Have singleton disposition behave differently from switch

We had SINGLETON_TAB and SWITCH_TO_TAB dispositions sharing a code
path. This change separates them such that singletons only search in
the current window for a tab, and fall-back to new-foreground-tab
instead of current-tab.

TBR=krb@chromium.org

(cherry picked from commit cc983247c218b60efbf1de5fe3e1f6f12dcaf160)

Bug:  807171 ,  807550 
Change-Id: I0fb3bb75806269df0916359d4c89246640241660
Reviewed-on: https://chromium-review.googlesource.com/896745
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Kevin Bailey <krb@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#534279}
Reviewed-on: https://chromium-review.googlesource.com/902195
Reviewed-by: Kevin Bailey <krb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#309}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/d7e23eff72fe2872f607e27730c41d90ca68cdec/chrome/browser/ui/browser_navigator.cc
[modify] https://crrev.com/d7e23eff72fe2872f607e27730c41d90ca68cdec/chrome/browser/ui/browser_navigator_browsertest.cc

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

commit 4155242a950f88e8f47ac9eae74291ad7d2f718e
Author: Kevin Bailey <krb@chromium.org>
Date: Mon Feb 05 21:17:13 2018

[browser nav] Remove FALLTHROUGH macro

...from GetBrowserAndTabForDisposition(). It's not available in M65.

Bug:  807171 ,  807550 
Change-Id: I8afb8ad2fef03030ed08a41660eaab3b21dbe358
TBR: thestig@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/902174
Reviewed-by: Kevin Bailey <krb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#320}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/4155242a950f88e8f47ac9eae74291ad7d2f718e/chrome/browser/ui/browser_navigator.cc