Closed Bug 1056617 Opened 10 years ago Closed 10 years ago

crash in mozilla::layers::AsyncPanZoomController::OnPan(mozilla::PanGestureInput const&, bool)

Categories

(Core :: Panning and Zooming, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla34

People

(Reporter: julian.viereck, Assigned: botond)

References

Details

Attachments

(1 file)

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.
Depends on: 1039992
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
Blocks: 1039992
No longer depends on: 1039992
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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 :)
Attached patch bug1056617.patchSplinter Review
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+
See Also: → 1056932
(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.
https://hg.mozilla.org/mozilla-central/rev/feb73cba8e7f
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: