1397461 - Assertion failure: mCoalescedInputEvent->buttons == aEvent.buttons, at dom/ipc/CoalescedMouseData.cpp:33

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: backtrace

I just tripped the following assertion failure in a local enable-debug disable-optimize build (based off of mozilla-central changeset c959327c6b75 ):
===
Assertion failure: mCoalescedInputEvent->buttons == aEvent.buttons, at dom/ipc/CoalescedMouseData.cpp:33
===

Backtrace attached.

My STR were:
 1. ./mach run https://bugzilla.mozilla.org/attachment.cgi?id=8905243
 2. Wait a little while (maybe 5 minutes)
 3. Click a blank space in the middle of the page.

At this point I don't have any confidence that these are reliable (or particularly specific) STR, though.

Comment 1

[Daniel Holbert [:dholbert]]

Looks like this assertion was added recently in bug 1361067. Adding dependency.

Comment 2

[Daniel Holbert [:dholbert]]

In my instance of hte assertion failure, here are the settings of various variables:

   mCoalescedInputEvent->buttons = 1
   aEvent.buttons = 0

(note that these ^^ are different values -- hence the assertion)

Aside from this difference, mCoalescedInputEvent and aEvent are largely the same. The only other fields that differ are mTime, mTimeStamp, mRefPoint, and mFocusSequenceNumber (which differs by 1).

I'll post their contents as attachments, in case it's handy.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: contents of mCoalescedInputEvent when the assertion fails

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: contents of aEvent when the assertion fails (obsoleting due to stray blank line at the beginning)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: contents of aEvent when the assertion fails

Comment 6

[Daniel Holbert [:dholbert]]

I just managed to trigger this again, after a minute of playing around left-clicking + right-clicking that same document.

This time the values were reversed from comment 2, though -- this time, I have:
(gdb) p mCoalescedInputEvent->buttons
$1 = 0
(gdb) p aEvent.buttons
$2 = 1

Comment 7

[Daniel Holbert [:dholbert]]

Triggered it again.

STR (which reliably cause the bug on my linux laptop, within about 10 seconds)
 1. Visit about:blank in a debug build. (Probably any page will do.)
 2. Furiously mash left + right click as fast as possible (at the same time / alternating back and forth).
    Use one hand per button, to be faster / more aggressive about simultaneous/rapid clicking.

ACTUAL RESULTS:
Within about 10 seconds, your tab will crash with...
> Assertion failure: mCoalescedInputEvent->buttons == aEvent.buttons, at dom/ipc/CoalescedMouseData.cpp:33


needinfo=stone to make a call about what this means, and potentially to fix it (or to relax the assertion severity if it's not a big deal)

Comment 8

[Daniel Holbert [:dholbert]]

BTW, I triggered this with an external bluetooth mouse (Logitech M310) as well as with my ThinkPad built-in trackpad's dedicated left/right-click buttons.

Comment 9

[Ming-Chou Shih [:stone]]

(In reply to Daniel Holbert [:dholbert] from comment #8)
> BTW, I triggered this with an external bluetooth mouse (Logitech M310) as
> well as with my ThinkPad built-in trackpad's dedicated left/right-click
> buttons.
Thanks for reporting this problem.

Comment 10

[Ming-Chou Shih [:stone]]

Attachment: Fire coalesced mousemove event when the event button or buttons changes

The assert is hit when we are sending mouse move events with button or buttons changes without sending mouseup or mousedown events. Tried on my desktop but can't reproduce it. I'll find a laptop for further testing later.

Created a patch to dispatch the coalesced mouse move event when the button or buttons changes in the incoming mouse move event.

Comment 11

[Daniel Holbert [:dholbert]]

Patch seems to fix it for me! I did notice some instances of this warning in my terminal output when furiously mashing mousebuttons, though:

[Parent 30519] WARNING: Wrong button set to eContextMenu event?: 'mMessage != eContextMenu || button == ((mContextMenuTrigger == eNormal) ? eRightButton : eLeftButton)', file ../../dist/include/mozilla/MouseEvents.h, line 277

Not sure if that's at all related to this patch and/or this coalescing feature, but thought I'd mention it just in case.

Comment 12

[Ming-Chou Shih [:stone]]

(In reply to Daniel Holbert [:dholbert] from comment #11)
> Patch seems to fix it for me! I did notice some instances of this warning in
> my terminal output when furiously mashing mousebuttons, though:
> 
> [Parent 30519] WARNING: Wrong button set to eContextMenu event?: 'mMessage
> != eContextMenu || button == ((mContextMenuTrigger == eNormal) ?
> eRightButton : eLeftButton)', file ../../dist/include/mozilla/MouseEvents.h,
> line 277
> 
> Not sure if that's at all related to this patch and/or this coalescing
> feature, but thought I'd mention it just in case.

May I have your help to test if the warning message exists after turning off the preference 'dom.event.coalesce_mouse_move'? The warning message tells us that we create an eContextMenu message with a button other than the right button.

Comment 13

[Daniel Holbert [:dholbert]]

Sure. Yeah, with my same STR (comment 7), I trigger that warning even in a profile where I've disabled that pref. (This is still with your patch applied, to avoid tripping the fatal assertion.)  So I think that means the warning is unrelated to your work here.

Comment 14

[Ming-Chou Shih [:stone]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2d7434ce796df272e6888efe1abcd3057f85507f

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7cd030c5483a
Fire coalesced mousemove event when the event button or buttons changes. r=smaug.

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/7cd030c5483a