Very unclear to me where to send this bug. I suspect it's not Blink, however.

avi: PTAL?

→ Becky who did the Android work in this area.

I think this is most likely related to that the foremost logic for Android is not taking account of the foremost PWA. I'll take a look now.

Avi and Ted,

I need your advice on whether the web app can steal the user focus when the it is in background. From a security perspective, do you think we should
  1) make the WebAppActivity foreground and show the JS dialog
  2) auto dismiss the dialog
  3) it doesn't matter so whatever is simplest to handle

I personally think 2) makes more sense since that matches the tab's behavior. WDYT?

Some background of PWA for Avi: (from my understanding) User can add a website to the Android home screen, and launch the website in another window (which is not the window for Chrome).

If the PWA is already in the background, it shouldn't be able to steal focus, which is 2). I thought the OP was complaining that the dialogs didn't show up when the PWA was the frontmost app.

@#6 & 7, I agree that the second approach is correct, but I believe Avi is also correct that the issue is that the prompt isn't showing at all even when in the foreground (just tested locally).

I think the issue might be that WebAppActivity uses SingleTabActivity which isn't accessible in native at all.  If the checks for foremost, we might need to null check on the tab model and then fall back to TabAndroid::IsUserInteractable.

Yes I understand the issue on the OP, just working on it and found that SingleTabModel is never tracked by the TabModelList, and am considering how to handle the current model if multiple web apps are running. That's why I asked:)

NP. Totally 2) in the situation from comment 6. None of this focus stealing baloney.

TBH, I don't know why the SingleTabModel isn't exposed to native.  That seems like a odd thing for clients to have to understand, and I wouldn't be opposed to making that the desired longer term solution.  I suspect there might be gotchas with sync that we'd need to rack our brains on to try and figure out why we did it that way in the first place.

Maybe the best thing in the short term would be to add a static to TabModelList natively that could internalize this check and handle the fallback for this case to just TabAndroid.

Hm... I was suspecting there was never a case we need to access the single tab model in native before.. Actually there is a single_tab_model.cc for the SingleTabModel, so I was thinking that we can add the SingleTabModel that extends TabModel in native, but make the super class's profile_ field null so that sync doesn't actually happen. What about this approach?

I personally would vote for an explicit single on the model like "ShouldSync" instead of setting the profile to null.  I'd rather it be fully functional but provide any additional information to prevent it from being misused.  CCTs already migrated to a full blown model anyway (no longer the singletabmodel that they once were), so I wonder what they did for sync.

Talked to yusufo@ offline and he mentioned for the custom tab activity, the signal still plumbs up to the SyncedWindowDelegateAndroid. There are types (isTypeTabbed, isTypePopup, isApp) that decides whether sync should happen (doesn't seem like on android though).

For the SingleTabActivity, beside what you mention in comment #14, we can also modify SyncedWindowDelegateAndroid::ShouldSync() [1] with the use of a parameter from constructor, or use of an existing or new type to decide.

[1] https://cs.chromium.org/chromium/src/chrome/browser/sync/glue/synced_window_delegate_android.cc?type=cs&q=ShouldSync

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

commit fa30ba1453daeb40194e3e9727ea996348804d3a
Author: Becky Zhou <huayinz@chromium.org>
Date: Mon Aug 27 03:42:57 2018

[TabModal] Short-term fix for JS dialog not showing in web apps

Use tab interactivity if tab model is not found in the tab model list.

Bug: 875595
Change-Id: I5fd69ed11e2f30733a25eaa98e353a98fc026a5e
Reviewed-on: https://chromium-review.googlesource.com/1188753
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Becky Zhou <huayinz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586187}
[modify] https://crrev.com/fa30ba1453daeb40194e3e9727ea996348804d3a/chrome/browser/ui/javascript_dialogs/javascript_dialog_tab_helper.cc

Requesting a merge to M69 for a small patch (+10/-2) that fixes JavaScript popups not showing on PWAs after JavaScript tab modal dialog launched (Issue 799334) on M68.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

Approved for merge into 69, branch 3497.

Here's a summary of the rules that were executed: 
 - OnlyMergeApprovedChange: Rule Failed -- Revision e1ac1843f5bd32d4f0a6fb8910ea5629c7c69b81 was merged to refs/branch-heads/3497 branch with no merge approval from a TPM! 
Please explain why this change was merged to the branch!

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

commit e1ac1843f5bd32d4f0a6fb8910ea5629c7c69b81
Author: Becky Zhou <huayinz@chromium.org>
Date: Wed Aug 29 20:21:55 2018

[TabModal] Short-term fix for JS dialog not showing in web apps

Use tab interactivity if tab model is not found in the tab model list.

TBR=tedchoc@chromium.org

Bug: 875595
Change-Id: I5fd69ed11e2f30733a25eaa98e353a98fc026a5e
Reviewed-on: https://chromium-review.googlesource.com/1188753
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Becky Zhou <huayinz@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#586187}(cherry picked from commit fa30ba1453daeb40194e3e9727ea996348804d3a)
Reviewed-on: https://chromium-review.googlesource.com/1195819
Reviewed-by: Becky Zhou <huayinz@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#844}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/e1ac1843f5bd32d4f0a6fb8910ea5629c7c69b81/chrome/browser/ui/javascript_dialogs/javascript_dialog_tab_helper.cc

Re #20: Ben, the label you added for merge approval is not for M69. Do we need to fix that label?

Oops, let me fix the label. Finger trouble. Removed the violation labels also.

Removing approval label now as it's merged.

Works as per expected behavior, Issue is verified on 69.0.3497.76 and 70.0.3537.2