Closed Bug 698154 (native_droid_gesture) Opened 11 years ago Closed 11 years ago

Use native gestures for scrolling and clicking

Categories

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

defect

Tracking

(fennec11+)

RESOLVED DUPLICATE of bug 704579
Tracking Status
fennec 11+ ---

People

(Reporter: wesj, Assigned: cwiiis)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached patch WIP demo (obsolete) — Splinter Review
In bug 695460 I was playing with using native gestures for longtap. We can also use them to detect the difference between things like scrolling, tapping, and "flings" (kinetic panning).

WIP works for panning but breaks clicking. Grrr... may not be as pretty as I'd hoped.
Attachment #570427 - Attachment is patch: true
Assignee: nobody → wjohnston
Priority: -- → P4
Attached patch WIP 2Splinter Review
Unbitrot and follow up work. This enables some tap highlighting because 1.) there is a delay between finger up and click, and 2.) Cancelling all the normal mousedowns means the tap highlight we do have goes away/fires to quickly to see. 

Clicks are fixed, but clicking on text fields causes... strange things. I sorta understand the P4 here, but this fixes things like selection during panning, so I consider it a little higher priority? Yell if you disagree.
Attachment #570427 - Attachment is obsolete: true
Blocks: 701706
I think this has become more important than a P4. Bumping to P2
Priority: P4 → P2
This patch no longer applies at all. Chris Lord said via irc he was doing this same thing with the new panning backend today? Hope I didn't misunderstand!
Assignee: wjohnston → chrislord.net
Alias: native_droid_gesture
I'm working on something similar for birch, but the event handling is pretty wildly different so I wouldn't count it as duplicated work - we may want the same thing for xul fennec too?
Hmm... happy to take this back and leave it open. I'm not really sure of the right answer here either. I'd leave XUL Fennec alone, as it already has most of the logic for this written and fairly well debugged.

Just jotting down rambling notes:
For multitouch, I'm planning to dispatch all finger down/up/move etc events to Gecko anyway. If those aren't preventDefaulted by content, and if there is only one touch point, we then also fire the corresponding mouse event (right now we aren't dispatching motion events to Gecko at all unless we think its a click).

This gesture detector code gives us access to Android native touchdown (i.e. do tap highlight!), scroll started (get rid of that tap highlight!), and click (do a click and get rid of the tap highlight) events. We could try sending those events to browser.js and redispatching them as mouse events using nsDOMWindowUtils. Then I'd just kill the mouseevents coming from nsWindow.cpp so that we weren't duplicating (and somehow leave that logic in for XUL Fennec?). Or we could send them to nsWindow.cpp and have it dispatch the correct events from there?

That first option feels a bit... wrong to me. There's no way for the widget code to fire mouse events at that point (probably better to fix later, but I'd like Fennec to work with a mouse on things like the Transformer as well)... I think I'm happier with the second. It also adds something else I will have to disable when the page is consuming TouchEvents.

OR! We could just not use those events at all, pick up touchevents in browser.js, and write our own logic there (i.e. steal from input.js) for dispatching mouse events?
This sounds like it goes slightly beyond the scope of what I'm doing (just replacing hand-written code with Android API usage), but I also like the second option of using nsWindow to dispatch the events and sending touch events from Android (there's API in Honeycomb 3.1 for mouse events too, I think, and stylus events in 4.0?)

If the events we want to dispatch match the Android events to some extent, we really oughtn't try to write our own logic to derive them from the raw events. Android has a lot more context to go on - this is part of the reason why I was doing this in the first place; a device I'm testing on ends up having two duplicate motion events before touch-up, so was breaking the kinetic scrolling. The scroll/fling events from android, on the other hand, work fine.

It sounds like there are two parts to this - the Android native side (+ JNI bindings perhaps), and the DOM event side. I'm happy to help out with the former, but it sounds like you're much better versed on the latter!
The native GestureDetector does a lot of integer truncation and rounding. It results in weird behavior on my Droid X. I think I'd be in favor of leaving it the way it is -- it's not that much code.
The cause of this is dragging while a kinetic pan was happening - This is my error, it should be easily fixed.

I'm still in favour of using the Android API. Devices are likely to have many different quirks and we'd be better off relying on the device manufacturer fixing these in the Android gesture detector than to write a general-purpose piece of code that we expect to work on every device.

If we aren't going to go with the Android API, which would take some effort, it'd be good to get some metrics that supports our decision.
ack, we're commenting on the wrong bug - moving conversation to bug #703311
This seems to have really split into bug #704579, bug #703311 and bug #703573. Marking this as a dupe.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 704579
tracking-fennec: --- → 11+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.