crash in mozilla::widget::MouseScrollHandler::LastEventInfo::InitWheelEvent(nsWindowBase*, mozilla::WidgetWheelEvent&, mozilla::widget::ModifierKeyState const&)
Categories
(Core :: Widget: Win32, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox64 | --- | affected |
People
(Reporter: masayuki, Unassigned)
Details
(Keywords: crash, Whiteboard: tpi:+, qa-not-actionable, [win:stability])
Crash Data
Updated•10 years ago
|
Updated•9 years ago
|
Comment 1•7 years ago
|
||
Comment 2•7 years ago
|
||
Comment 3•7 years ago
|
||
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Closing because no crashes reported for 12 weeks.
Comment 5•4 years ago
•
|
||
There is at least one crash from a December build: https://crash-stats.mozilla.org/report/index/e55659e2-39f8-4cd2-8b0b-6bc6e0211222#tab-details
Minidumps suggest that GetScrollAmount is actually returning something that can lead to a (rounded) zero (anything above 120 will do). It seems that GetScrollAmount can, in some cases, return a user pref value (mousewheel.windows.vertical_amount_override or mousewheel.windows.horizontal_amount_override) so it can be anything. I believe you can also manually tweak these numbers in Windows (GETWHEELSCROLLLINES/GETWHEELSCROLLCHARS). We should check the value before the divide. Maybe we can get away with using a small number in case we calculate 0.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•3 years ago
|
||
Very low crash rate, only on older versions, lowering severity.
Updated•3 years ago
|
Description
•