Closed Bug 1369074 Opened 3 years ago Closed 3 years ago

Crash in mozilla::layers::APZCTreeManager::StartScrollbarDrag (on about: pages only)

Categories

(Core :: Panning and Zooming, defect, P1, critical)

defect

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- verified

People

(Reporter: tracy, Assigned: botond)

References

Details

(Keywords: crash, reproducible, Whiteboard: [gfx-noted])

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-169ff542-249e-49c2-933d-4920b0170531.
=============================================================


There are reports of this on Window NT and Mac OS X. It just started with the latest Nightly, 55.0a1, 20170531030204.

I crashed with only about:newtab open.  The browser seemed to crash when I clicked away from the window (click on desktop), but that may have been coincidental.  I haven't reproduced the crash yet.  One install on Mac has already submitted two reports.
discovered reliable STR's

1) Open a new tab  (about:newtab, command+T or "+" in tab bar)
2) ensure the window is small enough that the vertical scroll bar is present
3) click on the scroll bar

tested result: CRASH

expected result:  scroll bar is clickable for mouse sliding

note:  mouse wheel scrolling and touch pad scrolling of about:newtab works fine.
Keywords: reproducible
I haven't seen this on regular web pages.  Seem to be reproducible only on a variety of about: pages.
Summary: Crash in mozilla::layers::APZCTreeManager::StartScrollbarDrag → Crash in mozilla::layers::APZCTreeManager::StartScrollbarDrag (on about: pages only)
Thanks for the STR, I am able to repro.
Assignee: nobody → botond
Component: XUL → Panning and Zooming
Priority: -- → P1
Whiteboard: [gfx-noted]
Duplicate of this bug: 1369079
Crash Signature: [@ mozilla::layers::APZCTreeManager::StartScrollbarDrag] → [@ mozilla::layers::APZCTreeManager::StartScrollbarDrag] [@ mozilla::layers::APZCTreeManager::NotifyScrollbarDragRejected]
There was a latent bug in nsBaseWidget::StartAsyncScrollbarDrag(), where a uint64_t value (the roots layers ID) was temporarily coerced into a 32-bit variable, losing the top 32 bits.

This latent bug was exposed by the recently landed bug 1366915, which changed the way layers IDs are allocated to make use of the top 32 bits all the time.
Blocks: 1366915, 1199885
Comment on attachment 8873120 [details]
Bug 1369074 - Store the layers id in a variable of the proper type (uint64_t) in nsBaseWidget::StartAsyncScrollbarDrag().

https://reviewboard.mozilla.org/r/144592/#review148446
Attachment #8873120 - Flags: review?(bugmail) → review+
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8709ce04de16
Store the layers id in a variable of the proper type (uint64_t) in nsBaseWidget::StartAsyncScrollbarDrag(). r=kats
https://hg.mozilla.org/mozilla-central/rev/8709ce04de16
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Today's Nightly update no longer crashes clicking the scrollbar on about: pages.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.