Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/c3ea6f59b346bb589573f286465b9dd137119366..7987e9767be6e2a3459db0779dfb8664056eccf1?pretty=fuller&n=100

Suspecting: r387097 ?

Kindly help to re-assign if your change is not the cause for this issue.

Note: Above issue is note reproducible on Mac OS.

Deleted: Actual_desktop.mp4 741 KB

Actual_desktop.mp4 741 KB Download

adding RB-label, please change if required.

I believe this is a desired change.

Before, this thing looked like a modal dialog but acted like a bubble (dismissing when it lost focus). I don't think this disjointedness was intentional. Now it looks and acts as a modal dialog (it throbs when you try to click outside it, you have to explicitly close). +hwi to confirm new behavior

QQ: I'm on 52.0.2708.0. Does 52.0.2712.0 have a different version? 

not entirely sure, can you use canary?

I only tested on 52.0.2708.0 on CrOS (i.e. Add to Shelf). 

It should behave like "Cast" dialog e.g. 
1) The content area should not be navigable, 
2) On reload, the dialog should close, 
3) The dialog should not carry over to a new tab. 

The "Add to Shelf" didn't do any of those, but, just stayed over on top of everything, which should be fixed. Was I testing on a bad build, should I test on a windows machine to observe the issue correctly? Do the behaviors 1),2),3) above make sense? 

fyi: my windows machine has an issue at the moment.

This bug is just about a new behavior in "Add to desktop". If that doesn't exist on CrOS, you'll have to borrow someone's windows machine.

The only change that happened was that this thing which looked like a modal dialog now behaves like one as well. If we want to change how modal dialogs behave, that is an issue for future work.

Just tested. 

From my understanding, only blocking the content area interaction but not blocking the toolbar area interaction is how Chrome's modal has been behaved: e.g. Print, Credit card verification, Credential Manager API account chooser, allows to interact with the toolbar controls e.g. refresh, tabs. Is it intentional to change this Chrome modal behavior on "Add to desktop"?

Those are tab modal dialogs. This is browser modal. Compare to extension installation dialog.

Good to know the distinction. Thanks. 

I think "Add to desktop" should use Tab Modal. Do you think differentlY? 

(Probably for future work) I feel we should consider using Tab Modal only for all modals because the functions are typically called in a continuum of what the user was doing on the tab. Also I think it's useful and natural for user to be able to change context by going to another tab or to refresh/close/update the same tab via toolbar and tabstrip interaction.

ainslie@ - could you provide any input to clarify the modal behavior?

To add to #11, "extension installation dialog" uses Tab Modal on Mac. :-0

Sometimes it can be hard or impossible to make a dialog tab modal (due to implementation details). In this case I think it would be possible to do. But I don't think tab modal is always better. If it's a dialog that

a) is easy to get to (i.e. just click an item in a menu and it pops up immediately)
b) has little in the way of state

I don't see much purpose in allowing the user to interrupt and return to this flow. They can just as easily dismiss and re-initiate it later.

In either case, I think we're getting away from the original purpose of this bug. It sounds like the old behavior was not the desired behavior. Perhaps the new behavior is not the desired either, but it's closer.

re: #11 
Hwi, I'd be interested in an audit to see if we could unify modality (either tab or window) on Desktop. And also that we should split that off from this bug. Tab modal in this case SGTM.

re: #8 
I agree that if it looks modal, it should behave modally. 

Archiving old bugs that haven't been modified in over two years. 

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!