Could you attach a net-internals log if you believe this was an authentication issue with Chrome's network stack? Instructions here: http://dev.chromium.org/for-testers/providing-network-details

However, a cursory look through the device logs leaves me with the impression that this was not an authentication failure on part of Chrome.

Indeed, this is not network auth issue. It is herb problem.

If I disable elderberry in M61, the issue went away. If I force elderberry in M60, it is also broken.

Also if I don't have any default browser, I get browser chooser and then select Dev and always, the problem went away too. In this case, a new activity stack is opened after auth.

The NextAction date has arrived: 2017-08-14

Ideally, we can get this fixed before going to Stable. Any idea what's going on here Yusuf?

Didn't have a chance to look yet. Is herb going stable in 61?

Yes that's the target

The best I can do about this is promise to triage and identify the issue by end of this week.

Thanks that would be great to do.

Here is the activity dump when it got stuck

Display #0 (activities from top to bottom):
  Stack #1:
  mFullscreen=true
  mBounds=null
    Task id #655
    mFullscreen=true
    mBounds=null
    mMinWidth=-1
    mMinHeight=-1
    mLastNonFullscreenBounds=null
      TaskRecord{fed9416 #655 A=com.philips.lighting.hue2 U=0 StackId=1 sz=3}
      Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.philips.lighting.hue2/.ContentActivity }
        Hist #2: ActivityRecord{9ef3fe9 u0 com.philips.lighting.hue2/.ContentActivity t655}
          Intent { dat=phhueandroidappl2://authenticate?code=OXpZ6wnv&state=h0mA flg=0x10020004 cmp=com.philips.lighting.hue2/.ContentActivity (has extras) }
          ProcessRecord{9646504 6383:com.philips.lighting.hue2/u0a142}
        Hist #1: ActivityRecord{6a94cfc u0 com.chrome.dev/org.chromium.chrome.browser.customtabs.CustomTabActivity t655}
          Intent { act=android.intent.action.VIEW dat=https://api.meethue.com/oauth2/auth?response_type=code&clientid=UOfV0ckcVkmnbHSe1H9alB2zPB2N15YN&appid=hue_android_app&deviceid=49496735757735324b3779726c434372&devicename=Google%20Pixel%202&state=h0mA&redirect_uri=phhueandroidappl2%3a%2f%2f flg=0x800000 cmp=com.chrome.dev/org.chromium.chrome.browser.customtabs.CustomTabActivity (has extras) }
          ProcessRecord{b493232 5567:com.chrome.dev/u0a133}
        Hist #0: ActivityRecord{2229ee6 u0 com.philips.lighting.hue2/.ContentActivity t655}
          Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.philips.lighting.hue2/.ContentActivity bnds=[35,252][237,514] }
          ProcessRecord{9646504 6383:com.philips.lighting.hue2/u0a142}
    Task id #654
    mFullscreen=true
    mBounds=null
    mMinWidth=-1
    mMinHeight=-1
    mLastNonFullscreenBounds=null
      TaskRecord{94f0f84 #654 I=com.android.settings/.applications.InstalledAppDetailsTop U=0 StackId=1 sz=1}
      Intent { act=android.settings.APPLICATION_DETAILS_SETTINGS dat=package:com.philips.lighting.hue2 flg=0x10008000 cmp=com.android.settings/.applications.InstalledAppDetailsTop }
        Hist #0: ActivityRecord{a8dd751 u0 com.android.settings/.applications.InstalledAppDetails t654}
          Intent { act=android.settings.APPLICATION_DETAILS_SETTINGS dat=package:com.philips.lighting.hue2 flg=0x10008000 cmp=com.android.settings/.applications.InstalledAppDetails bnds=[63,450][641,597] }
          ProcessRecord{8d207ad 24073:com.android.settings/1000}
    Task id #608

Here is a summary of what is happening:

Philips Hue main Activity is a non single instance Activity, and in normal operation, they rely on the fact that when they intent out to a browser app, the browser is singleTask, so it creates the tab in a new task.

When we start enabling Herb, we create Herb tabs on the same task if we can. This breaks their flow, because when they send another intent for their Activity, it creates another instance of it on top of the Herb tab's Activity.

Right now the task stack is: Hue1 -> CustomTabActivity -> Hue2

What this means: All non single task/instance apps that uses an authentication flow relying on browser being on a different task will have broken flows.

Possible ways to fix:
1- Open all herb tabs in a new task. This is a bit extreme UI change, but would make these problems go away.
2- Open any new intent a herb tab sends out in a new task. This still changes the current UI flow, but is less extreme than above. I am favoring this one.

ktam@, tedchoc@ please let me know if we are OK with moving forward with 2 above.

+Maria, I thought we explicitly add new task if we construct an intent when handling click.

I suspect in this case, the link url is explicitly an intent url.

Grace is correct -- we always set FLAG_ACTIVITY_NEW_TASK when we intercept and dispatch page clicks. In fact, we would set this flag even if the URL is intent://.

Yusuf, the part I am not following is why you'd expect that adding NEW_TASK flag when dispatching back to Hue would fix the issue?

If this flow is broken because Hue expects to have a single ContentActivity of their own, then there might not be much we can do other than having all herb tabs open in their own tasks.

I was mostly betting on the flow being broken because this same activity on the same task (their implementation of onNewIntent maybe) is causing the problem here.

And AFAICT we are not adding NEW_TASK on this situation, since the second Hue activity is still launching on the same task. For herb tabs, we do use the default ExternalNavigationHandler and not use any custom tabs specific logic. Wonder where the logic breaks there.

Yusuf and I discussed in person and Yusuf is planning to test out a solution where we will add FLAG_ACTIVITY_CLEAR_TOP to the external intents as well, which may allow us to correctly route these to the initial activity.

Last M61 Beta is planning to roll out on Wednesday, going to stable 1 week later.  Changes must by in by Tuesday afternoon.

IMO, it's too late to make this change for M-61. We should probably delay the rollout of Herb to M-62 -- but it's up to Ted & Kingston make that decision. It does seem like this might affect a number of apps.

On my end, I can land this probably tomorrow, but Maria is right that this is one change that might actually use some testing time on beta. I will leave it up to the decider to make that call as well.

But I will try to land the CL tomorrow to trunk.

That's fine. We can punt for M62.

Did we land a fix for M62?

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

commit 576e1ad4ef6b9c6584cc243fea48eba216ca69d2
Author: Maria Khomenko <mariakhomenko@chromium.org>
Date: Tue Sep 12 23:23:12 2017

Call out to external intents with FLAG_ACTIVITY_CLEAR_TOP.

This should ensure that if a Chrome activity is running at the top of an
existing task, an activity in that task would get re-targeted, if
possible.

BUG= 747551 

Change-Id: Idcdb52ae2b677897e8819ae3e1da70768ed676cc
Reviewed-on: https://chromium-review.googlesource.com/663878
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Maria Khomenko <mariakhomenko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501448}
[modify] https://crrev.com/576e1ad4ef6b9c6584cc243fea48eba216ca69d2/chrome/android/java/src/org/chromium/chrome/browser/externalnav/ExternalNavigationHandler.java

I submitted the proposed fix, but wasn't able to test it locally as I didn't have a suitable app.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-62; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-62 label, otherwise remove Merge-TBD label. Thanks.

Pushing this to M-63. We want to give this time to bake.

@Grace - can you confirm that Chrome Beta works with Hue/Herb combination now?