Crash in [@ nsRangeFrame::GetValueAtEventPoint]

RESOLVED FIXED in Firefox 68

Status

()

defect
P1
critical
RESOLVED FIXED
Last month
Last month

People

(Reporter: marcia, Assigned: smaug)

Tracking

({crash, regression})

Trunk
mozilla69
Unspecified
Android
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 wontfix, firefox67 wontfix, firefox68 fixed, firefox69 fixed)

Details

(crash signature)

Attachments

(2 attachments)

This bug is for crash report bp-5547e6e3-9fd4-4174-9385-1b8f30190611.

Seen while looking at 67.0.1 crash stats for mobile: https://bit.ly/2Kb5vvg. Crashes occurred back to at least 63, but in 67.0.1 it is currently the #2 overall top crash.

Comments are not useful and the correlations don't show anything. APIs range from 22-28 and some phones from Oppo and Vivo are the top crashing devices currently.

Top 10 frames of crashing thread:

0 libxul.so nsRangeFrame::GetValueAtEventPoint xpcom/base/nsCOMPtr.h:823
1 libxul.so mozilla::dom::HTMLInputElement::StartRangeThumbDrag dom/html/HTMLInputElement.cpp:3462
2 libxul.so mozilla::dom::HTMLInputElement::PostHandleEventForRangeThumb xpcom/ds/nsTArray.h
3 libxul.so mozilla::dom::HTMLInputElement::PostHandleEvent dom/html/HTMLInputElement.cpp:4196
4 libxul.so mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:556
5 libxul.so mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:633
6 libxul.so mozilla::EventDispatcher::Dispatch dom/events/EventDispatcher.cpp:1048
7 libxul.so mozilla::PresShell::EventHandler::DispatchEvent layout/base/PresShell.cpp:8261
8 libxul.so mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo layout/base/PresShell.cpp:7700
9 libxul.so mozilla::PresShell::EventHandler::HandleEventUsingCoordinates layout/base/PresShell.cpp:6716

Looks like null + offset crash.

Assignee: nobody → bugs
Priority: -- → P1
Posted file range_crash.html

testcase, try to drag the range thumb using mouse.

This should be the minimal patch to fix the issue (should be safe for branches too).

Reusing an existing mouse/touch test for the crash testing.

Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4e074fb72148
ensure range element has a frame before starting drag operation, r=hsivonen
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Comment on attachment 9071619 [details]
Bug 1558546, ensure range element has a frame before starting drag operation, r=hsivonen

Beta/Release Uplift Approval Request

  • User impact if declined: Crashes
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Basically doing a null check.
  • String changes made/needed: NA
Attachment #9071619 - Flags: approval-mozilla-beta?

Comment on attachment 9071619 [details]
Bug 1558546, ensure range element has a frame before starting drag operation, r=hsivonen

simple crash fix, approved for 68.0b10

Attachment #9071619 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.