Starting out, assuming that you can intuit whether you're handling a user event by inspecting the event dispatcher is very optimistic, and the comment above that block is a good example about timing problems this approach can have even before we start carving ash out of chrome, which makes things even more asynchronous. I suspect that an approach that assumes that an event is handled in one pass through the message loop is wrong.
CL introduced the check: https://codereview.chromium.org/55303003
The issue it addresses is to ensure that dragging a tab off a visiting browse window of user B in user A's desktop does not end up in an invisible browser window. We would need a different solution.
Right now, the window to which user's desktop info is stored inside MultiUserWindowManagerChromeOS. This would not work for mash for sure. Maybe we should store it as part of the window, e.g. as a window property. This would make the code more mash ready. And for the original tab dragging problem, we can say the new browser window should inherit the property of where the tab is detached from.
erg, can you take this? It's our mustash refactoring that broke it; it seems like we should fix it. I'm not sure that warx@ is any more familiar with this code than we are. If you're too busy I can take it.
warx@, if you've made progress on this feel free to take back the bug.
Comment 1 by e...@chromium.org
, Feb 8 2017