GestureEventListener should use gesture related system settings on platforms that support them

RESOLVED INCOMPLETE

Status

()

Core
Panning and Zooming
RESOLVED INCOMPLETE
4 years ago
3 years ago

People

(Reporter: jimm, Unassigned)

Tracking

26 Branch
x86_64
Windows 8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [feature] p=0)

(Reporter)

Description

4 years ago
GestureEventListener currently uses a set of internal constants for short/long/double tap durations. On Windows these durations should come from the system since they can be changed by the user via the control panel.

For the time being metrofx is using the winrt gesture recognizer to work around this.
Is it a feasible approach to ensure that all of these values are controllable by prefs, and then have the winrt widget code twiddle the prefs as needed? Presumably there's some way to listen for changes in the system settings that control these durations.

If that doesn't work then the sanest option is to not use GestureEventListener on winrt and pipe in your own gesture events to the APZC.
(Reporter)

Comment 2

4 years ago
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> Is it a feasible approach to ensure that all of these values are
> controllable by prefs, and then have the winrt widget code twiddle the prefs
> as needed? Presumably there's some way to listen for changes in the system
> settings that control these durations.
> 
> If that doesn't work then the sanest option is to not use
> GestureEventListener on winrt and pipe in your own gesture events to the
> APZC.

Yes we can use nsLookAndFeel if we think the value is something the user might want to customize for the app.
Whiteboard: [release28]
(Reporter)

Comment 3

4 years ago
This doesn't block, we can continue to use the winrt gesture recognizer for this until we get around to fixing this bug.
Whiteboard: [release28]
How do we distinguish between "doesn't block" and "hasn't been triaged"?
(Reporter)

Comment 5

4 years ago
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)
> How do we distinguish between "doesn't block" and "hasn't been triaged"?

Currently an empty white board indicates that. We just have to be careful about marking [triage]/blocking flags on any new bugs we file. Alternatively we could start marking non-blocking with something like [notblocking].
noting that when this is implemented, the doubletap to zoom code will likely need to be modified. Bug 895581 has some wip patches that might be useful in that case.

Updated

4 years ago
Blocks: 861680
No longer blocks: 886321
(Reporter)

Updated

4 years ago
Whiteboard: [feature]

Updated

4 years ago
Whiteboard: [feature] → [feature] p=0
There is nothing that needs to be done on this big at this point since we're not working on metro. Closing for now; we can revisit this issue if necessary for APZ on desktop.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.