Closed Bug 1056617 Opened 6 years ago Closed 6 years ago
crash in mozilla::layers::Async
Pan Zoom Controller::On Pan(mozilla::Pan Gesture Input const&, bool)
The latest nightly is very crashy to me. You can find crash reports here: https://crash-stats.mozilla.com/report/index/610a53a0-64e6-4315-a8b3-213f12140821 Doing a regression range analysis, I came up with this range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=111a1da2a95d&tochange=ffdd1a398105 From this range, bug 1039992 seems most likely to me to have caused this regression. I have a local web page, where I can reproduce this issues (it seems to be related with scrolling CodeMirror). Let me know if I should try to reduce the issue there.
Thanks for reporting the crash! I assume you're just running regular OS X nightly builds but with the "layers.async-pan-zoom.enabled" pref set to true? The crash is probably a null mPanGestureState when we enter OnPan. Not really sure why that would happen since OnPanBegin should get called first but I didn't look at it that closely.
Assignee: nobody → botond
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #1) > I assume you're just running regular OS X > nightly builds but with the "layers.async-pan-zoom.enabled" pref set to true? Yes, this is right :)
Discussed this with Markus on IRC. The problem is that the patch in bug 1039992 assumes that PANGESTURE_PAN events are received between PANGESTURE_START and PANGESTURE_END (or PANGESTURE_MOMENTUMSTART and PANGESTURE_MOMENTUMEND) events. In PANGESTURE_START, we build the overscroll handoff chain, and in PANGESTURE_END, we clear it. In PANGESTURE_PAN, we expect it to exist. Prior to bug 1039992, it was baiscally the same except if the handoff chain wasn't built, it was empty rather than not existing at all. The handler for PANGESTURE_PAN calls DispatchScroll(), which is a no-op if the handoff chain is empty. Effectively, PAN events that were not between START and END events were ignored. With bug 1039992, we now crash in such a situation. This patch restores the original behaviour of not panning instead. Markus also said that some devices legitimately send PAN events that are not between START and END events, so rather than ignoring such events, we should handle them properly. I'll file a follow-up bug for this.
Attachment #8476796 - Flags: review?(mstange)
Attachment #8476796 - Flags: review?(mstange) → review+
(In reply to Botond Ballo [:botond] from comment #3) > Markus also said that some devices legitimately send PAN events that are not > between START and END events, so rather than ignoring such events, we should > handle them properly. I'll file a follow-up bug for this. Filed bug 1056932.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.