Using the per-revision bisect providing the bisect results,
Good build: 58.0.3004.0 (Revision: 448183).
Bad build: 58.0.3005.2 (Revision: 448507).

You are probably looking for a change made after 448203 (known good), but no later than 448204 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/aca84dc37eb032e7ed985a19597a233b6f491fcc..5d64ae77225a34b5e439216e5cf3ea643b9ea29b

From the CL above, assigning the issue to the concern owner

@sadrul : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2669303005
Note : Windows 10.0 specific issue and Able to reproduce in latest Canary #58.0.3032.0

I am not sure what the bug is ... I see the bidirectional arrow show up in both videos?

With response to comment #2: On restoring down the first time bidirectional arrow is seen, but after maximizing and restoring back, bidirectional arrow is not seen.

Interesting to note that only the arrow is broken. If you hold down your (left) mousebutton on the border you can actually just resize your window.

Nonetheless, having an arrow is quite convenient.

Friendly Ping! Still able to reproduce the issue on Win 10.0 using latest chrome version 59.0.3048.0.

sadrul@ Could you please look into this issue.

Thanks!

In the first video, after the chrome window is resized + maximized + restored, the bidirectional arrow still shows up several times. So I am afraid I still do not understand what the bug is.

Starting at 8 seconds and later, the arrow has a noticably shorter time it shows than in the expected case.

This seems to be 'fixed'. At least in the latest dev build my arrow is just working as it did previously.

 Issue 717600  has been merged into this issue.

 Issue 706435  has been merged into this issue.

 Issue 734024  has been merged into this issue.

--> varkha@ Maybe you could look at this? This is related to window-targeting in aura, I think (of course, not caused by the recent changes you have made, since this bug is older than any of those changes)

Is it really a side effect of https://codereview.chromium.org/2669303005 ?

It could be. I haven't had a chance to look into it. If it is, we are probably breaking some code that's making assumptions about the window hierarchy, which changed because of the removal of the extra container window.

I won't be able to work on this anytime soon so returning to the queue for triage.

Archiving old bugs that haven't been actively assigned in over 180 days.

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