Fix behavior of WindowEventDispatcher::SynthesizeMouseMoveEvent().

Fix behavior of WindowEventDispatcher::SynthesizeMouseMoveEvent().

Synthetic mouse events should be generated when window bounds changes such
that the cursor previously outside the window becomes inside, or vice versa,
but subject to the following conditions:

- If one or more mouse buttons is down, we should synthesize MOUSE_DRAGGED
event instead of MOUSE_MOVED, and also set the appropriate mouse button flags.
- Do not generate synthesized mouse move events for windows that ignore events, such
as the cursor window, because they do not accept synthesized events and pass them
directly to the windows beneath.

After this fix we can safely re-enable cursor compositing mode.

BUG=363651
TEST=trybot and manual testing
R=derat@chromium.org, sadrul@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=264669

[hshi1, 2014-04-14 21:54:49]

PTAL. I propose that we do not synthesize mouse-move event when the
OnWindowBoundsChanged occurs for the cursor window.

Per sadrul's comment at https://codereview.chromium.org/150403005#msg4: "the
mouse-move event is synthesized to make sure that the cursor gets updated (and
the window under the cursor gets the correct hover
effect in the right location). This shouldn't apply for the cursor window".

This CL uses the window's ignore_events() method to determine if the synthesized
event should be dropped.

[Daniel Erat, 2014-04-14 21:56:39]

lgtm (although i don't know much about this, so you should hold off for sadrul's
lgtm too) :-)

[sadrul, 2014-04-14 22:21:10]

Can you explain why the synthesized mouse-move event breaks text-dragging?

You should add test coverage for the change.

[hshi1, 2014-04-14 22:23:57]

On 2014/04/14 22:21:10, sadrul wrote:
> Can you explain why the synthesized mouse-move event breaks text-dragging?
> 
> You should add test coverage for the change.

See https://code.google.com/p/chromium/issues/detail?id=362693#c18

The synthesized mouse-move event breaks up a continuous stream of MOUSE_DRAGGED
events when user performs text drag-selection.

Actual sequence of events that disrupts drag-select (with the problematic event
highlighted)

ET_MOUSE_PRESSED, ET_MOUSE_DRAGGED, ET_MOUSE_DRAGGED, ET_MOUSE_MOVED,
ET_MOUSE_DRAGGED, ET_MOUSE_RELEASED
                                                      ^^^^^^^^^^^^^^

[sadrul, 2014-04-14 22:27:33]

On 2014/04/14 22:23:57, hshi1 wrote:
> On 2014/04/14 22:21:10, sadrul wrote:
> > Can you explain why the synthesized mouse-move event breaks text-dragging?
> > 
> > You should add test coverage for the change.
> 
> See https://code.google.com/p/chromium/issues/detail?id=362693#c18
> 
> The synthesized mouse-move event breaks up a continuous stream of
MOUSE_DRAGGED
> events when user performs text drag-selection.
> 
> Actual sequence of events that disrupts drag-select (with the problematic
event
> highlighted)
> 
> ET_MOUSE_PRESSED, ET_MOUSE_DRAGGED, ET_MOUSE_DRAGGED, ET_MOUSE_MOVED,
> ET_MOUSE_DRAGGED, ET_MOUSE_RELEASED
>                                                       ^^^^^^^^^^^^^^

Sounds like we don't want to generate synth-mouse-moves when there's an active
drag happening.

[hshi1, 2014-04-14 22:37:57]

On 2014/04/14 22:27:33, sadrul wrote:
> Sounds like we don't want to generate synth-mouse-moves when there's an active
> drag happening.

I'm not sure if this is always applicable in general. Wouldn't it be safer to
target this very narrow scenario? If the window has ignore_events() set to true
then we will certainly have no need to generate synth-mouse-moves.

[sadrul, 2014-04-14 23:00:21]

On 2014/04/14 22:37:57, hshi1 wrote:
> On 2014/04/14 22:27:33, sadrul wrote:
> > Sounds like we don't want to generate synth-mouse-moves when there's an
active
> > drag happening.
> 
> I'm not sure if this is always applicable in general. Wouldn't it be safer to
> target this very narrow scenario? If the window has ignore_events() set to
true
> then we will certainly have no need to generate synth-mouse-moves.

Other windows also set ignore_events() bit, and so this is not necessarily a
narrow scenario.

Dispatching a mouse-move event during a drag sounds broken, and will potentially
cause issues in other places too. So preventing that would be a good fix.
(although perhaps synthesizing a mouse-drag event, instead of not synthesizing
any event at all, might make more sense).

Not synthesizing touch-moves for windows with ignore_events set also sounds
reasonable, but synthesizing a mouse-move event in the cursor location in such
cases should effectively be a no-op anyway.

[hshi1, 2014-04-15 00:06:50]

sadrul: I tried to override the event_type to MOUSE_DRAGGED for the synthesized
event but text selection is still broken. I think it is fundamentally incorrect
because even though we've modified the event_type, the mouse location for the
synthesized DRAG may be completely different from the actual sequence of user
DRAG events, so it may still break up drag.

[hshi1, 2014-04-15 00:27:03]

On 2014/04/15 00:06:50, hshi1 wrote:
> sadrul: I tried to override the event_type to MOUSE_DRAGGED for the
synthesized
> event but text selection is still broken. I think it is fundamentally
incorrect
> because even though we've modified the event_type, the mouse location for the
> synthesized DRAG may be completely different from the actual sequence of user
> DRAG events, so it may still break up drag.

@sadrul - Regarding the approach to not generate synth-mouse-moves when
dragging: I find it difficult to determine whether we're dragging. Using
WindowEventDispatcher's |mouse_pressed_handler_| member is not a reliable
indicator. Any suggestions?

>> Other windows also set ignore_events() bit, and so this is not necessarily a
narrow scenario.

Understood but it is still a fairly narrow scenario, and it seems pretty safe to
assume that any window with ignore_events set will not require the synthesized
event. So do you find this acceptable? Thanks.

[hshi1, 2014-04-15 00:37:30]

Alternatively, if there's any way to make the cursor "window" not generate any
events when its bound changes, that would be perfect too. The only purpose of
the cursor "window" is to draw the cursor on top of everything else, and itself
should not be generating or handling any events.

[hshi1, 2014-04-15 01:05:22]

@sadrul: PTAL patch set #2.

I propose to remove the previous hack in mouse_cursor_event_filter.cc.

Instead, we should make it clear that the mouse cursor window is disallowed to
generate synthesized events. Towards that end, I've added a new flag
("disallow_synthesize_events") so that it can be used to uniquely identify the
cursor window, instead of getting confused with other windows that may also set
the "ignore_events" flag.

[sadrul, 2014-04-15 01:33:19]

not lgtm. We should not need to add to the aura api for this.

Perhaps you can look at Env::IsMouseButtonDown() to decide whether or not to
generate drag events. (also, please make sure to add sufficient test coverage in
all places that you are changing existing behaviour).

[hshi1, 2014-04-15 01:40:13]

On 2014/04/15 01:33:19, sadrul wrote:
> not lgtm. We should not need to add to the aura api for this.
> 
> Perhaps you can look at Env::IsMouseButtonDown() to decide whether or not to
> generate drag events. (also, please make sure to add sufficient test coverage
in
> all places that you are changing existing behaviour).

@sadrul - Please reconsider. Do understand that this problem is not limited to
dragging. The hack I am removing is related to the screen magnifier. IMHO we
should not generate synthesized events for the cursor window under all
circumstances.

[hshi1, 2014-04-15 01:45:59]

On 2014/04/15 01:40:13, hshi1 wrote:
> On 2014/04/15 01:33:19, sadrul wrote:
> > not lgtm. We should not need to add to the aura api for this.
> > 
> > Perhaps you can look at Env::IsMouseButtonDown() to decide whether or not to
> > generate drag events. (also, please make sure to add sufficient test
coverage
> in
> > all places that you are changing existing behaviour).
> 
> @sadrul - Please reconsider. Do understand that this problem is not limited to
> dragging. The hack I am removing is related to the screen magnifier. IMHO we
> should not generate synthesized events for the cursor window under all
> circumstances.

Also I have already mentioned earlier that your suggestion (generate drag
instead of move when mouse is down) does not work.

[hshi1, 2014-04-15 02:23:16]

+sky (OWNER of ui/aura) because sadrul has shot down my patch set.

I think we have a misunderstanding of the problem, but I disagree with sadrul's
proposal to generate synthesized DRAGGED events when mouse is down, because it
does not address the root cause of the issue.

The root cause is that the concept of "synthesized events" do not apply to the
cursor windows. Normal windows interact with the cursor and handle cursor
events, but the Ash cursor window is unique because by design it is never to
interact with cursor; itself *is* the cursor. Therefore we call
set_ignore_events(true) so that any mouse event gets dispatched to the window
beneath it.

For the same reason, we should never generate synthesized events when the cursor
window bound changes. The cursor window bounds change when and only when the
cursor moves (because the cursor window contains the bitmap of the cursor, and
by setting the bounds of the cursor window, we effectively draw the cursor to
the new position on screen). If we synthesize a mouse event upon window bounds
change, it will simply get passed through to the windows beneath the cursor
window, and that will disrupt user operation.

[hshi1, 2014-04-15 04:35:34]

See also (internal partner bug:
https://code.google.com/p/chrome-os-partner/issues/detail?id=28034)

This shows that simply generating DRAG event when mouse button is pressed won't
solve the real issue.

[oshima, 2014-04-15 07:21:29]

https://codereview.chromium.org/237893002/diff/20001/ui/aura/window_event_dis...
File ui/aura/window_event_dispatcher.cc (right):

https://codereview.chromium.org/237893002/diff/20001/ui/aura/window_event_dis...
ui/aura/window_event_dispatcher.cc:688: !window->disallow_synthesize_events()) {
can't we simply check ignore_events here?

[hshi1, 2014-04-15 07:41:49]

On 2014/04/15 07:21:29, oshima (OOO April 11 - 21) wrote:
>
https://codereview.chromium.org/237893002/diff/20001/ui/aura/window_event_dis...
> File ui/aura/window_event_dispatcher.cc (right):
> 
>
https://codereview.chromium.org/237893002/diff/20001/ui/aura/window_event_dis...
> ui/aura/window_event_dispatcher.cc:688: !window->disallow_synthesize_events())
{
> can't we simply check ignore_events here?

Initially I proposed to simply check ignore_events() here (see patch set #1) but
sadrul's comment was that other windows use ignore_events too so it may not be a
narrow scenario.

But the new patch set seems to affect more code, so maybe I'd revert to patch
set #1?

[hshi1, 2014-04-15 08:29:47]

Note that in principle I believe it is 100% correct to disallow generating
synthesized events for windows that has "ignore events" set.

Reason: "ignore event" means events dispatched to the window are to be directly
passed to the windows beneath it.

But if an event is synthesized upon the window bounds or visibility changes, we
obviously want to dispatch the synthesized event for the target window only. It
should not be passed to the windows beneath it.

Therefore it seems that we would never want to generate synthesized events for
"ignore events" windows. WDYT?

[sadrul, 2014-04-15 11:03:12]

On 2014/04/15 08:29:47, hshi1 wrote:
> Note that in principle I believe it is 100% correct to disallow generating
> synthesized events for windows that has "ignore events" set.
> 
> Reason: "ignore event" means events dispatched to the window are to be
directly
> passed to the windows beneath it.
> 
> But if an event is synthesized upon the window bounds or visibility changes,
we
> obviously want to dispatch the synthesized event for the target window only.
It
> should not be passed to the windows beneath it.
> 
> Therefore it seems that we would never want to generate synthesized events for
> "ignore events" windows. WDYT?

As I have explained in previous comments, not synthesizing events for
ignore-events windows sounds reasonable. But as you have explained in #msg4
here, we are generating mouse-move events in the middle of a drag, and that's
what is causing the problem. The solution I am suggesting is to either not
synthesize a MOVED event during a drag, or to synthesize a DRAGGED event instead
of a MOVED event. You are saying generating a DRAGGED event does not fix the
issue. Can you explain more how you are generating the DRAGGED event, and why it
didn't fix the issue? Have you tried not synthesizing the MOVED event when a
drag is in-progress?

[hshi1, 2014-04-15 13:44:16]

On 2014/04/15 11:03:12, sadrul wrote:
> On 2014/04/15 08:29:47, hshi1 wrote:
> > Note that in principle I believe it is 100% correct to disallow generating
> > synthesized events for windows that has "ignore events" set.
> > 
> > Reason: "ignore event" means events dispatched to the window are to be
> directly
> > passed to the windows beneath it.
> > 
> > But if an event is synthesized upon the window bounds or visibility changes,
> we
> > obviously want to dispatch the synthesized event for the target window only.
> It
> > should not be passed to the windows beneath it.
> > 
> > Therefore it seems that we would never want to generate synthesized events
for
> > "ignore events" windows. WDYT?
> 
> As I have explained in previous comments, not synthesizing events for
> ignore-events windows sounds reasonable. But as you have explained in #msg4
> here, we are generating mouse-move events in the middle of a drag, and that's
> what is causing the problem. The solution I am suggesting is to either not
> synthesize a MOVED event during a drag, or to synthesize a DRAGGED event
instead
> of a MOVED event. You are saying generating a DRAGGED event does not fix the
> issue. Can you explain more how you are generating the DRAGGED event, and why
it
> didn't fix the issue? Have you tried not synthesizing the MOVED event when a
> drag is in-progress?

Thanks I'll try more experiments today. For now I'm removing the patch set #2 as
it seems unnecessary to add the "disallow synthesized events" flag.

[hshi1, 2014-04-15 17:11:10]

On 2014/04/15 13:44:16, hshi1 wrote:
> On 2014/04/15 11:03:12, sadrul wrote:
> > As I have explained in previous comments, not synthesizing events for
> > ignore-events windows sounds reasonable. But as you have explained in #msg4
> > here, we are generating mouse-move events in the middle of a drag, and
that's
> > what is causing the problem. The solution I am suggesting is to either not
> > synthesize a MOVED event during a drag, or to synthesize a DRAGGED event
> instead
> > of a MOVED event. You are saying generating a DRAGGED event does not fix the
> > issue. Can you explain more how you are generating the DRAGGED event, and
why
> it
> > didn't fix the issue? Have you tried not synthesizing the MOVED event when a
> > drag is in-progress?

As you suggested, I am using Env::GetInstance()->IsMouseButtonDown() to
determine whether mouse button is down.

Here's my observations:
(1) If we do not synthesize any event during a drag, then it indeed fixes the
problem;
(2) If we generate a DRAG when button is down, then text selection is still
broken, even though I verified that DRAG events are generated correctly.

I still don't understand what's breaking drag-select in case (2). I suspect that
merely setting the EF_IS_SYNTHESIZED flag will cause unforeseen side effects.

[hshi1, 2014-04-15 22:11:09]

sadrul - PTAL patch set #3.

I have added aura unittest
WindowEventDispatcherTest.SynthesizeMouseEventsOnWindowBoundsChanged to verify
that:

(1) When window bounds change that causes cursor inside the window to become
outside (or vice versa), it receives synthetic mouse moves;

(2) However if the window is set to ignore events, then no synthetic mouse moves
are received.

I'd prefer to disallow synthetic events for all windows that ignore events
because it feels like the right thing to do. You're right that we can probably
check if mouse button is down and only do so when dragging, but even if
generating synthetic moves for mouse button up is a no-op it is still not right
or necessary.

[sadrul, 2014-04-16 16:17:55]

On 2014/04/15 17:11:10, hshi1 wrote:
> On 2014/04/15 13:44:16, hshi1 wrote:
> > On 2014/04/15 11:03:12, sadrul wrote:
> > > As I have explained in previous comments, not synthesizing events for
> > > ignore-events windows sounds reasonable. But as you have explained in
#msg4
> > > here, we are generating mouse-move events in the middle of a drag, and
> that's
> > > what is causing the problem. The solution I am suggesting is to either not
> > > synthesize a MOVED event during a drag, or to synthesize a DRAGGED event
> > instead
> > > of a MOVED event. You are saying generating a DRAGGED event does not fix
the
> > > issue. Can you explain more how you are generating the DRAGGED event, and
> why
> > it
> > > didn't fix the issue? Have you tried not synthesizing the MOVED event when
a
> > > drag is in-progress?
> 
> As you suggested, I am using Env::GetInstance()->IsMouseButtonDown() to
> determine whether mouse button is down.
> 
> Here's my observations:
> (1) If we do not synthesize any event during a drag, then it indeed fixes the
> problem;
> (2) If we generate a DRAG when button is down, then text selection is still
> broken, even though I verified that DRAG events are generated correctly.
> 
> I still don't understand what's breaking drag-select in case (2). I suspect
that
> merely setting the EF_IS_SYNTHESIZED flag will cause unforeseen side effects.

Do you have new insight on why (2) doesn't work? If you don't set the
SYNTHESIZED flag on the DRAGGED event, does that fix the problem? Or are there
other reasons?

[hshi1, 2014-04-16 17:52:27]

On 2014/04/16 16:17:55, sadrul wrote:
> On 2014/04/15 17:11:10, hshi1 wrote:
> > On 2014/04/15 13:44:16, hshi1 wrote:
> > > On 2014/04/15 11:03:12, sadrul wrote:
> > > > As I have explained in previous comments, not synthesizing events for
> > > > ignore-events windows sounds reasonable. But as you have explained in
> #msg4
> > > > here, we are generating mouse-move events in the middle of a drag, and
> > that's
> > > > what is causing the problem. The solution I am suggesting is to either
not
> > > > synthesize a MOVED event during a drag, or to synthesize a DRAGGED event
> > > instead
> > > > of a MOVED event. You are saying generating a DRAGGED event does not fix
> the
> > > > issue. Can you explain more how you are generating the DRAGGED event,
and
> > why
> > > it
> > > > didn't fix the issue? Have you tried not synthesizing the MOVED event
when
> a
> > > > drag is in-progress?
> > 
> > As you suggested, I am using Env::GetInstance()->IsMouseButtonDown() to
> > determine whether mouse button is down.
> > 
> > Here's my observations:
> > (1) If we do not synthesize any event during a drag, then it indeed fixes
the
> > problem;
> > (2) If we generate a DRAG when button is down, then text selection is still
> > broken, even though I verified that DRAG events are generated correctly.
> > 
> > I still don't understand what's breaking drag-select in case (2). I suspect
> that
> > merely setting the EF_IS_SYNTHESIZED flag will cause unforeseen side
effects.
> 
> Do you have new insight on why (2) doesn't work? If you don't set the
> SYNTHESIZED flag on the DRAGGED event, does that fix the problem? Or are there
> other reasons?

sadrul: if I don't set the SYNTHESIZED flag on the DRAGGED event, it still does
NOT fix the problem. Unfortunately so far I still don't have a plausible
explanation why that is the case because it appears the synthesized DRAGGED
event have correct locations.

There's a few states affected when posting the synthesized event (for example,
|synthesize_mouse_move_|, and it seems to interact with other methods of this
class). I am really not familiar with this class and if you insist I can keep
spending time debugging this.

However, you mentioned earlier that it is acceptable to simply disallow
synthesized events based on ignore_events(), and I already have that working
(with a unit test), so WDYT?

[hshi1, 2014-04-16 19:12:55]

@sadrul: oh I see what the problem is. It is not enough to set event type to
_DRAGGED because it is ignored by RenderWidgetHostImpl. The latter only cares
about blink event modifiers which are converted from the event  flags. So, I
need to set the flag ui::EF_LEFT_MOUSE_BUTTON too.

I've verified in WindowEventDispatcher::SynthesizeMouseMoveEvent() if I set
event type to DRAGGED and set EF_LEFT_MOUSE_BUTTON flag when mouse button is
down then it fixes the problem.

[hshi1, 2014-04-16 20:34:52]

sadrul: PTAL Patch Set 4. I have fixed the problem with synthetic MOUSE_DRAGGED
events when mouse button is down. Also added unit tests to cover this case.
Thanks!

[sadrul, 2014-04-17 15:39:54]

Thanks! lgtm

https://codereview.chromium.org/237893002/diff/100001/ui/aura/window_event_di...
File ui/aura/window_event_dispatcher_unittest.cc (right):

https://codereview.chromium.org/237893002/diff/100001/ui/aura/window_event_di...
ui/aura/window_event_dispatcher_unittest.cc:875:
EXPECT_FALSE(filter->mouse_event_flags().empty());
The above two should be ASSERT, so that the test stops. Otherwise, the following
two lines will end up causing a crash. (the same for other such checks below)

[hshi1, 2014-04-17 17:24:25]

https://codereview.chromium.org/237893002/diff/100001/ui/aura/window_event_di...
File ui/aura/window_event_dispatcher_unittest.cc (right):

https://codereview.chromium.org/237893002/diff/100001/ui/aura/window_event_di...
ui/aura/window_event_dispatcher_unittest.cc:875:
EXPECT_FALSE(filter->mouse_event_flags().empty());
On 2014/04/17 15:39:54, sadrul wrote:
> The above two should be ASSERT, so that the test stops. Otherwise, the
following
> two lines will end up causing a crash. (the same for other such checks below)

Done.

[hshi1, 2014-04-17 18:11:02]

Unfortunately it looks like the synthesized DRAGGED event is crashing
DragDropController unit tests. The synthesized events do not have valid
OSExchangeData in the DragDropData (I have added some debug logs and it looks
like the DragDropData got released as soon as the DragDropController initiates
Drag):

==26813==ERROR: AddressSanitizer: SEGV on unknown address 0x02007f4759dc (pc
0x00000108810c sp 0x7fffd1f67240 bp 0x7fffd1f67270 T0)
    #0 0x108810b in HasString ui/base/dragdrop/os_exchange_data.cc:85
    #1 0x108810b in ui::OSExchangeData::HasAnyFormat(int,
std::set\u003Cui::Clipboard::FormatType,
std::less\u003Cui::Clipboard::FormatType>,
std::allocator\u003Cui::Clipboard::FormatType> > const&) const
ui/base/dragdrop/os_exchange_data.cc:103
    #2 0x130c22a in views::DropHelper::CalculateTargetViewImpl(gfx::Point
const&, ui::OSExchangeData const&, bool, views::View**)
ui/views/widget/drop_helper.cc:108
    #3 0x130bb04 in views::DropHelper::OnDragOver(ui::OSExchangeData const&,
gfx::Point const&, int) ui/views/widget/drop_helper.cc:32
    #4 0x12ceb57 in OnDragEntered ui/views/widget/native_widget_aura.cc:918
    #5 0x12ceb57 in non-virtual thunk to
views::NativeWidgetAura::OnDragEntered(ui::DropTargetEvent const&)
ui/views/widget/native_widget_aura.cc:920
    #6 0x13df7db in ash::DragDropController::DragUpdate(aura::Window*,
ui::LocatedEvent const&) ash/drag_drop/drag_drop_controller.cc:268
    #7 0x6fbacd in ash::test::(anonymous
namespace)::TestDragDropController::DragUpdate(aura::Window*, ui::LocatedEvent
const&) ash/drag_drop/drag_drop_controller_unittest.cc:178
    #8 0x13e0a5d in ash::DragDropController::OnMouseEvent(ui::MouseEvent*)
ash/drag_drop/drag_drop_controller.cc:370
    #9 0x110013f in DispatchEvent ui/events/event_dispatcher.cc:189
    #10 0x110013f in
ui::EventDispatcher::DispatchEventToEventHandlers(std::vector\u003Cui::EventHandler*,
std::allocator\u003Cui::EventHandler*> >*, ui::Event*)
ui/events/event_dispatcher.cc:168
    #11 0x10ff427 in ui::EventDispatcher::ProcessEvent(ui::EventTarget*,
ui::Event*) ui/events/event_dispatcher.cc:126
    #12 0x10fef80 in DispatchEventToTarget ui/events/event_dispatcher.cc:85
    #13 0x10fef80 in
ui::EventDispatcherDelegate::DispatchEvent(ui::EventTarget*, ui::Event*)
ui/events/event_dispatcher.cc:57
    #14 0x110204f in ui::EventProcessor::OnEventFromSource(ui::Event*)
ui/events/event_processor.cc:22
    #15 0x1056315 in aura::WindowEventDispatcher::SynthesizeMouseMoveEvent()
ui/aura/window_event_dispatcher.cc:712
    #16 0xeabb6e in Run base/callback.h:401
    #17 0xeabb6e in base::MessageLoop::RunTask(base::PendingTask const&)
base/message_loop/message_loop.cc:443
    #18 0xeae127 in DeferOrRunPendingTask base/message_loop/message_loop.cc:455
    #19 0xeae127 in base::MessageLoop::DoWork()
base/message_loop/message_loop.cc:569
    #20 0xf23987 in base::MessagePumpGlib::Run(base::MessagePump::Delegate*)
base/message_loop/message_pump_glib.cc:270
    #21 0xecb15e in Run base/run_loop.cc:49
    #22 0xecb15e in base::RunLoop::RunUntilIdle() base/run_loop.cc:55
    #23 0x16608d8 in ash::test::AshTestHelper::RunAllPendingInMessageLoop()
ash/test/ash_test_helper.cc:143
    #24 0x6ebea6 in
ash::test::DragDropControllerTest_CaptureLostCancelsDragDrop_Test::TestBody()
ash/drag_drop/drag_drop_controller_unittest.cc:832
    #25 0xfe1e7a in HandleExceptionsInMethodIfSupported\u003Ctesting::Test,
void> testing/gtest/src/gtest.cc:2045
    #26 0xfe1e7a in testing::Test::Run() testing/gtest/src/gtest.cc:2061
    #27 0xfe3ee8 in testing::TestInfo::Run() testing/gtest/src/gtest.cc:2237
    #28 0xfe4c63 in testing::TestCase::Run() testing/gtest/src/gtest.cc:2344
    #29 0xff5ab3 in testing::internal::UnitTestImpl::RunAllTests()
testing/gtest/src/gtest.cc:4065
    #30 0xff50a0 in
HandleExceptionsInMethodIfSupported\u003Ctesting::internal::UnitTestImpl, bool>
testing/gtest/src/gtest.cc:2045
    #31 0xff50a0 in testing::UnitTest::Run() testing/gtest/src/gtest.cc:3697
    #32 0xf9e014 in RUN_ALL_TESTS testing/gtest/include/gtest/gtest.h:2231
    #33 0xf9e014 in base::TestSuite::Run() base/test/test_suite.cc:207
    #34 0xf9471c in Run base/callback.h:401
    #35 0xf9471c in base::(anonymous namespace)::LaunchUnitTestsInternal(int,
char**, base::Callback\u003Cint ()> const&, int)
base/test/launcher/unit_test_launcher.cc:494
    #36 0xa469e4 in main ash/test/ash_unittests.cc:12
    #37 0x7f1fb14e976c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
    #38 0x4e150c in _start
(/mnt/scratch0/b_used/build/slave/linux_chromeos_asan/build/src/out/Release/ash_unittests+0x4e150c)

[hshi1, 2014-04-17 18:19:12]

sadrul - are you familiar with the DragDropControllerTest?

There's a "for" loop in the test and there appears to be a hack where, after
each iteration, we call UpdateDragData(&data) to set the |drag_data_| to a fake
drag data object, because the original data was already lost.

This trick breaks down when we synthesize a drag event -- it happens after the
original data was deleted, but before we got a chance to replace |drag_data_|
with a fake one.

[hshi1, 2014-04-17 18:48:56]

I propose Patch Set #6 to address the issue with DragDropControllerTest. I have
already verified locally that all tests under DragDropControllerTest as well as
WindowEventDispatcherTest are passing.

The change is to obtain the mouse_button_flags() at the same time we post
synthesized mouse move events. This ensures that we won't encounter a situation
where the button state is different when the window bounds first changed and
when we actually send the synthesized event. Also, we should only synthesize
DRAGGED events when mouse button is down AND there's a window bounds change. For
example, we should not synthesize DRAG when the window visibility changes.

[hshi1, 2014-04-17 19:47:29]

The CQ bit was checked by hshi@chromium.org

[commit-bot: I haz the power, 2014-04-17 19:48:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hshi@chromium.org/237893002/140001

[commit-bot: I haz the power, 2014-04-17 21:49:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-04-17 21:49:22]

Try jobs failed on following builders:
  tryserver.chromium on win_chromium_rel

[hshi1, 2014-04-17 21:53:49]

The CQ bit was checked by hshi@chromium.org

[commit-bot: I haz the power, 2014-04-17 21:54:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hshi@chromium.org/237893002/140001

[hshi1, 2014-04-17 22:33:37]

The CQ bit was checked by hshi@chromium.org

[commit-bot: I haz the power, 2014-04-17 22:35:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hshi@chromium.org/237893002/160001

[hshi1, 2014-04-17 23:24:06]

Committed patchset #7 manually as r264669 (presubmit successful).