Closed Bug 713011 Opened 8 years ago Closed 8 years ago

Can't scroll (getting tons of "GeckoPanZoomController: Finishing animation at ...")

Categories

(Firefox for Android :: General, defect, P2)

ARM
Android
defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking-fennec1.0 --- -
fennec 11+ ---

People

(Reporter: Margaret, Assigned: kats)

References

Details

Attachments

(3 files)

Attached file logcat
I attached my logcat dump, but it doesn't look too useful. After quitting/restarting I couldn't reproduce the issue.

I'm on today's Nightly, but I also experienced this yesterday. Both times it happened after I opened a link from twitter and experienced bug 713000, but I couldn't reproduce by doing that just now.
Assignee: nobody → bugmail.mozilla
I just saw this happen on my Galaxy Tab as well, logcat attached
Adding Cwiiis and pcwalton. I'm having a hard time understanding how this could possibly happen. It seems like there's a runaway AnimationTimer that just keeps running the runnable, which goes into finishAnimation() and runs that code. However the only way I can imagine getting into that state is if the PanZoomController is accessed on multiple threads, which it isn't - everything is done on the UI thread as of 30d3ae6f67d5. Any ideas?
Priority: -- → P2
Hardware: All → ARM
tracking-fennec: --- → 11+
I'm not sure if I should make this action more harsh, like killing Fennec, or just leave it at logging it. The problem with just logging is that it may happen once and scroll off the logcat before the error actually manifests with wonky behaviour.
Attachment #587832 - Flags: review?(blassey.bugs)
Comment on attachment 587832 [details] [diff] [review]
Add some code to check what thread is running

Review of attachment 587832 [details] [diff] [review]:
-----------------------------------------------------------------

Let's try this less severe approach for now and if we can't get the stack in a log we can make it fatal
Attachment #587832 - Flags: review?(blassey.bugs) → review+
Try run for this patch was green. https://tbpl.mozilla.org/?tree=Try&rev=f794bb9b8972

Landed on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/cd17d9409fda

Requesting leaving this bug open after merge to m-c because this is just logging to try and uncover the root cause.
Whiteboard: [leave open after inbound merge], [inbound]
https://hg.mozilla.org/mozilla-central/rev/cd17d9409fda
Whiteboard: [leave open after inbound merge], [inbound] → [leave open after inbound merge]
For now marking as not-fennec-11 since the patch that was applied is diagnostic for m-c, and will eventually be reverted.
Whiteboard: [leave open after inbound merge] → [leave open after inbound merge], not-fennec-11
Kats - What the status here? Do we need to worry about this anymore?
Haven't heard anybody complain about this in a good while. We can probably close it as WFM now, but I'm not sure if I should leave in the logging I added or not.
blocking-fennec1.0: --- → +
Status: NEW → ASSIGNED
blocking-fennec1.0: + → -
I'm going to go ahead and mark this is as closed. It seems to be fixed but we're always mucking about in the code so leaving the logging in seems like a reasonable thing to do to track down future regressions faster.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [leave open after inbound merge], not-fennec-11
You need to log in before you can comment on or make changes to this bug.