Closed Bug 1557411 Opened 3 years ago Closed 2 years ago

GV API to let app know if web content wants to handle gestures

Categories

(GeckoView :: General, defect, P1)

Unspecified
All

Tracking

(firefox70 wontfix, firefox71 fixed)

RESOLVED FIXED
mozilla71
Tracking Status
firefox70 --- wontfix
firefox71 --- fixed

People

(Reporter: cpeterson, Assigned: snorp)

References

Details

(Whiteboard: [geckoview:m1909])

Attachments

(2 files)

An app can map swipe gestures to back/forward navigation (bug 1509249) or pull-to-refresh (bug 1522446) commands, but it needs to know whether web content wants to handle those input events itself (e.g. swipe gestures in a game like Fruit Ninja).

James suggests a simple API so the app can ask if the web content has any input event handlers that might want to capture gestures.

Is this API a dupe of "Report when touch event listeners are registered" bug 1564195?

Depends on: 1564195
Rank: 44
Whiteboard: [geckoview:pwa:p2]

(In reply to Chris Peterson [:cpeterson] from comment #1)

Is this API a dupe of "Report when touch event listeners are registered" bug 1564195?

I think it makes sense to handle this in two bugs. I'll do the APZ portion in bug 1564195 and snorp or someone else on the GV team can do the GV portion in this bug.

(In reply to Botond Ballo [:botond] from comment #2)

I think it makes sense to handle this in two bugs. I'll do the APZ portion in bug 1564195 and snorp or someone else on the GV team can do the GV portion in this bug.

SGTM. In that case, I will change this bug's priority to P1 so the GV team will try to fix this bug for our current sprint (September 1-30).

Priority: P2 → P1

So the patches in bug 1564195 propagate the information as far as nsWindow::NPZCSupport::HandleMotionEvent(), in the form of result.mHitRegionWithApzAwareListeners.

The idea for this bug would be to propagate that further to whatever place in GeckoView wants to consume it.

Assignee: nobody → snorp

(In reply to Botond Ballo [:botond] from comment #4)

So the patches in bug 1564195 propagate the information as far as nsWindow::NPZCSupport::HandleMotionEvent(), in the form of result.mHitRegionWithApzAwareListeners.

(Code reference for this, now that the patches have landed and are reflected in Searchfox .)

Adding [geckoview:m1909] whiteboard tag because we'd like to fix this bug in September (because Fenix needs it to implement pull-to-refresh, one of their planned Q3 features).

https://github.com/mozilla-mobile/android-components/issues/3182

Whiteboard: [geckoview:m1909]
Pushed by jwillcox@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7821ada49c6b
Add GeckoView API to expose how touch events are handled. r=geckoview-reviewers,botond,agi
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Pushed by jwillcox@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/11e85f657592
Fix up some minor documentation issues r=geckoview-reviewers,agi

(In reply to Tiger Oakes from bug 1564195 comment #20)

I'm currently working on the pull to refresh implementation in A-C. When is the onTouchEventForResult method called? I haven't been able to trigger it when debugging.

@ James: a question from Tiger ^

(from Tiger's needinfo in bug 1564195 comment #20)

Flags: needinfo?(snorp)

(In reply to Chris Peterson [:cpeterson] from comment #13)
The app needs to call that directly, probably from something like NestedGeckoView

Flags: needinfo?(snorp)
You need to log in before you can comment on or make changes to this bug.