Closed Bug 859951 Opened 8 years ago Closed 8 years ago

Refactor the code to convert from MOTION_EVENT to nsTouchEvent instances

Categories

(Core :: Widget: Android, defect)

23 Branch
All
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla23

People

(Reporter: kats, Assigned: kats)

References

Details

Attachments

(2 files, 2 obsolete files)

Attached patch Refactor event creation code (obsolete) — Splinter Review
This I think reduces the code somewhat, and more importantly, allows me to reuse some of this for creating the input events I'll need for AsyncPanZoomController hookup.

This patch should have no functional changes.
Attachment #735329 - Flags: review?(wjohnston)
Also going to throw this on here. Again, no functional changes intended.
Attachment #735330 - Flags: review?(wjohnston)
Rebased, fixed bug number
Attachment #735329 - Attachment is obsolete: true
Attachment #735329 - Flags: review?(wjohnston)
Attachment #736270 - Flags: review?(wjohnston)
Attachment #735330 - Attachment is obsolete: true
Attachment #735330 - Flags: review?(wjohnston)
Attachment #736271 - Flags: review?(wjohnston)
Comment on attachment 736270 [details] [diff] [review]
(1/2) Refactor event creation code

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

::: widget/android/nsWindow.cpp
@@ +1202,5 @@
>      bool preventDefaultActions = false;
>      bool isDownEvent = false;
> +
> +    nsTouchEvent event = ae->MakeTouchEvent(this);
> +    if (event.message != NS_EVENT_NULL) {

Just to ask, are you sure we want to keep going if NS_EVENT_NULL at all? Maybe it'd be safer to just return early. Or maybe we have things we want to do later that should happen regardless...
Attachment #736270 - Flags: review?(wjohnston) → review+
Comment on attachment 736271 [details] [diff] [review]
(2/2) Use getActionMasked() and getActionIndex()

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

nice!
Attachment #736271 - Flags: review?(wjohnston) → review+
(In reply to Wesley Johnston (:wesj) from comment #4)
> Just to ask, are you sure we want to keep going if NS_EVENT_NULL at all?
> Maybe it'd be safer to just return early. Or maybe we have things we want to
> do later that should happen regardless...

I looked briefly at what happens if we don't return early, and I think we do want to keep it this way because of the prevent-default notification. If we miss that notification then things have the potential to go bad so I think it's safer to run that code if we have an unknown event type.
https://hg.mozilla.org/mozilla-central/rev/b978b9e5c2df
https://hg.mozilla.org/mozilla-central/rev/40dd2c59bd0e
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in before you can comment on or make changes to this bug.