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

Status: RESOLVED FIXED

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

Description

[:Margaret Leibovic]

Attachment: 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.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Attachment: Logcat with start of finishingAnimation

I just saw this happen on my Galaxy Tab as well, logcat attached

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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?

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Attachment: Add some code to check what thread is running

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.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

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

Comment 5

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 6

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/cd17d9409fda

Comment 7

[Kartikaya Gupta (email:[e-mail])]

For now marking as not-fennec-11 since the patch that was applied is diagnostic for m-c, and will eventually be reverted.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

Kats - What the status here? Do we need to worry about this anymore?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

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.