Closed Bug 1397461 Opened 2 years ago Closed 2 years ago

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

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 --- fixed

People

(Reporter: dholbert, Assigned: stone)

References

Details

(Keywords: assertion, regression)

Attachments

(4 files, 1 obsolete file)

Attached file 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.
Looks like this assertion was added recently in bug 1361067. Adding dependency.
Blocks: 1361067
Component: DOM: Events → Event Handling
Keywords: assertion
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.
Attachment #8905260 - Attachment description: contents of aEvent when the assertion fails → contents of aEvent when the assertion fails (obsoleting due to stray blank line at the beginning)
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
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)
Flags: needinfo?(sshih)
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.
Assignee: nobody → sshih
Flags: needinfo?(sshih)
(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.
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.
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.
(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.
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.
Attachment #8905757 - Flags: review?(bugs)
Attachment #8905757 - Flags: review?(bugs) → review+
Pushed by sshih@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7cd030c5483a
Fire coalesced mousemove event when the event button or buttons changes. r=smaug.
https://hg.mozilla.org/mozilla-central/rev/7cd030c5483a
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.