487617 - Moving mouse inside desktop window adds too many events to kinetic queue

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Ben Combee (:bcombee)]

05:51 <@mfinkle> bcombee: I pulled the latest source and panning seems broken
06:07 < bcombee> mfinkle: how?  what platform?
06:08 < bcombee> I don't see much kinetic on desktop, but it's working on my n810
06:18 < bcombee> I know that panning locking is broken now with stuart's recent
                 changes, working on getting that back in
06:23 < bcombee> hmmm, new bug I'm noticing
06:23 < bcombee> open a page, scroll down a ways, pan to left to bring up nav
                 buttons
06:24 < bcombee> at this time, you see the title bar
06:24 < bcombee> hit the star button to bookmark it
06:24 < bcombee> title bar goes away, leaving up the nav buttons and leaving a
                 checkerboard in the corner
06:28 <@mfinkle> yes, I have seen that one too
06:29 <@mfinkle> in my build (windows desktop), I get weird jumps whenever I pan
06:30 <@mfinkle> it's like the onMouseDown is moving the canvas somewhere and then
                 panning starts
06:31 < bcombee> yeah, so on the n810, we actually get mousemove events sent before
                 the mouse down
06:31 < bcombee> stuart was trying to optimize for that
06:31 < bcombee> but on desktop, those moves might be irrelevant
06:31 < bcombee> we may be buffering too many of them too, I'll double check
                 stuart's change
06:33 <@mfinkle> maybe

Comment 1

[Ben Combee (:bcombee)]

Attachment: Remove old events in momentum buffer in startKinetic

This should help a lot on desktop builds where mouseMoves can really accumulate, unlike the touchscreen devices where only a few will show up before the mouseDown.

Comment 2

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

Comment on attachment 371861 [details] [diff] [review]
Remove old events in momentum buffer in startKinetic

Problem is not fixed. I'm not convinced this is a kinetic problem. My initial mousedown seems to cause the jump.

I'll put some logging in to get some data.

Comment 3

[Ben Combee (:bcombee)]

OK, I think there still may be an issue with keeping too many mousemove events on desktop.  I'm going to alter this patch to work in addData instead of startKinetic to reduce memory pressure.

Comment 4

[Ben Combee (:bcombee)]

Attachment: Try #2 - move filter to addData instead of startKinetic

Not all the way there, but a starting point

Comment 5

[Stuart Parmenter]

Comment on attachment 371969 [details] [diff] [review]
Try #2 - move filter to addData instead of startKinetic

this doesn't really help

Comment 6

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

we shouldn't block on desktop only bugs

Comment 7

[Ben Combee (:bcombee)]

I don't think this is needed anymore, we've got workaround on desktop using pref to disable those early moves