I don't believe you can get away with suppressing the alert until the user returns to the old tab exactly. You can auto-dismiss it from the perspective of the web page, and then you could choose to either show the dialog or not when the user returns to the old tab. +Avi who may have more thoughts.

Showing it on return sounds reasonable to me. Presumably if they're alert()ing it's something the user is intended to see. (Even more so for prompt()/confirm().)

To my surprise, I think it's even allowed per the HTML5 spec, which says pausing is optional: http://w3c.github.io/html/webappapis.html#dom-window-alert

It depends on what you mean by "suppress". If you mean delaying showing it, no you can't. If you mean making it just not show up and immediately returning a result, sure.

What is the WebContentsDelegate of a new tab opened from a Custom Tab? It should just return true from WebContentsDelegate::ShouldSuppressDialogs (which uses "suppress" to mean "make it not show and immediately return to the javascript an answer").

As in that's infeasible or as in that's not a possible configuration today?

Going to leave the WebContentsDelegate question to Ian :)

"As in that's infeasible or as in that's not a possible configuration today?"

Can you please clarify your pronoun use here?

The use of the word "suppress" is problematic, so let's not use it.

In general, if a web site does a JavaScript alert, you **must** address it immediately. One way is to immediately return to the caller a result without showing any UI to the user. (That's what's referred to as "suppressing" the dialog in Chrome today.) Or you could immediately return to the caller a result and hold onto the string for later display to the user. (That works only for alert(), not for prompt() or confirm().) It seems that your UI precludes the option of switching to that background page immediately, which is the third option.

I hope that clears things up; feel free to drop a VC meeting on my calendar if you want to talk in real-time if you have questions.

Hi avi@, thanks for the precious info!

Currently WebContentDelegateAndroid does not override shouldSuppressDialog() and thus in Java code there is no control. I create a CL to actually make android code to have the option to override this value. Code review on the way! :)

Excellent.

To be clear, if WebContentsDelegate::ShouldSuppressDialogs() returns true, the "suppression" that happens is that the dialog never happens. There is no delay, the page gets told that the user clicked "OK" and nothing further happens.

If that works for you, that's good to hear.

And of course, I'm happy to take any JavaScript dialog reviews.

Hmm, it does unblock the flow, but I am not sure whether this is the right behavior as we essentially acknowledged the dialog user never see.

If we defer showing the dialog, it stalls the renderer for that tab, but the browser is still OK to handle other tab's messages, right?

I am not aware of a way to "stall a renderer". 

Also if we intentionally make the background renderer to halt, will other features, such as service worker, continue to work?

If you fail to respond on the browser side to a dialog, yes, that tab is jammed, but so is any other tab that shares a render process. And since your visible tab spawned the hidden tab, it likely shares the render process, and will likely jam as well.

Re #11, RunJavaSCriptMessage is a sync call ipc, so it "stall the renderer".

Re #12, for Chrome on Android, window.open opens a tab in the foreground, while context menu "open in new window" opens a tab in the background. In the former case, two share the same renderer, in the latter case, there will be two different renderer.

Fair enough. But it's still a bad idea to stall a renderer by not responding to the IPC. So far we've always responded to such calls immediately and I wouldn't recommend starting now.

(I saw the CL to address this, and I approve of that approach.)

In the case of CCT window.open, we should avoid stall as both tabs should be active. But if we use this concept to solve webapk to CCT transition, see crbug/636535, we may want to stall. We should explore a little deeper.

Okay then for CCT only, suppressing the background tab's dialog is the way to go then? :)

CL in review! https://chromiumcodereview.appspot.com/2233213002/

I still have the concern for suppressing the JS dialog as it can be misused.

I noticed currently we DO refocus the page triggered the JS dialog, and we put the previous top page to the back of the stack. I did find it if I keep hitting back.

So can we add a snackbar to "open the recently closed page"? If user says yes, we put it back on the top, otherwise we discard it.

Also see OldSpice, which is solving this problem on desktop.

Public doc:
https://docs.google.com/document/d/1wtV5rmLhbf1OZkbg7crtCt6h1mMtig_ctTQt3BLLEIU/edit

Note that OldSpice right now is desktop-only. Perhaps some of the ideas can be adapted to mobile, but I don't have the engineers right now to make this happen.

Given that alert() etc. from the background tab have been broken since we launched this and nobody has complained, should we just suppress dialogs? I think that's certainly better than the status quo.

Reassign to sbirch@ for this bug to reach a consensus.

I already had a CL to implement what sbirch@ said in #20. https://chromiumcodereview.appspot.com/2233213002/