Front-end code needs to be able to know whether or not the user uses (not just has) a touchscreen

RESOLVED FIXED in Firefox 55

Status

()

Core
Widget: Win32
P1
normal
RESOLVED FIXED
4 months ago
2 months ago

People

(Reporter: mconley, Assigned: jimm)

Tracking

unspecified
mozilla55
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox55 fixed)

Details

(Whiteboard: [photon-visual][tpi:+])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

4 months ago
Photon will, among other things, require the front-end being able to decide on how to display things to the user based on whether or not a touchscreen interface is enabled.

The actual specifics on how this information should be surfaced to the UI layer is unclear, but the work to actual do it should be in here.
(Reporter)

Comment 1

4 months ago
I _believe_ there are already a few places where the front-end already knows that a touchscreen is being used somehow, but I'm not certain it gives us 100% of what we need. I'll ask some of our front-end folk.
We have :-moz-touch-enabled psuedo-class, but do we instead want something that says that the touch screen has actually been used in this session?

For instance, I use a touchscreen laptop and I don't particularly like UI being huge if I'm using my mouse/keyboard. For the select popup work, we only show larger rows if the menu was opened via touch. I believe this latter route is what we should strive for.
(Assignee)

Updated

4 months ago
Priority: -- → P3
Whiteboard: tpi:+
Perhaps bug 1035774 is a good way of exposing this?
Stephen, it would probably help move this bug forward if we knew what kind of responsive behavior the UX team has in mind. Is this only about style changes such as making buttons larger and would you say it's sufficient to know if the device _has_ a touchscreen?
Flags: needinfo?(shorlander)

Updated

3 months ago
Summary: Front-end code needs to be able to know whether or not the user is using a touchscreen → Front-end code needs to be able to know whether or not the user uses (not just has) a touchscreen

Updated

3 months ago
Blocks: 1352356

Updated

3 months ago
No longer blocks: 1325171
Whiteboard: tpi:+ → [photon] tpi:+
(Assignee)

Comment 5

3 months ago
In metrofx we controlled this through a detection check that looked at pointer input event source. When the user touched the screen, the first input event would fire an observer event that triggered touch ui changes in front end code like removing the mouse cursor. Flipping back to cursor UX was triggered by another event based on mouse input.

https://hg.mozilla.org/projects/metro/file/tip/browser/metro/base/content/input.js#l1002

It should be pretty easy to do that in desktop as well. We could detect these transitions down in the widget input handling and fire an observer as a result.

Dao, would a check/event like this suffice?
Flags: needinfo?(dao+bmo)

Updated

3 months ago
Flags: needinfo?(dao+bmo)
Whiteboard: [photon] tpi:+ → [photon-visual][tpi:+]

Updated

3 months ago
Blocks: 1355771

Comment 6

3 months ago
(In reply to Jim Mathies [:jimm] from comment #5)
> In metrofx we controlled this through a detection check that looked at
> pointer input event source. When the user touched the screen, the first
> input event would fire an observer event that triggered touch ui changes in
> front end code like removing the mouse cursor. Flipping back to cursor UX
> was triggered by another event based on mouse input.
> 
> https://hg.mozilla.org/projects/metro/file/tip/browser/metro/base/content/
> input.js#l1002
> 
> It should be pretty easy to do that in desktop as well. We could detect
> these transitions down in the widget input handling and fire an observer as
> a result.
> 
> Dao, would a check/event like this suffice?

Sounds good. I don't think we care about the mouse cursor, and I suspect we don't want to respond to the notification immediately, but we can deal with that in front-end code. I filed bug 1355772 for getting a precise UX spec.
No longer blocks: 1352356
Flags: needinfo?(shorlander)

Updated

3 months ago
Blocks: 1256754

Comment 7

3 months ago
I hope you don't mind me bumping the priority here since this blocks two P2 bugs.
Priority: P3 → P2

Updated

3 months ago
Flags: qe-verify-
(Assignee)

Comment 8

2 months ago
Created attachment 8858371 [details] [diff] [review]
patch
Assignee: nobody → jmathies
Attachment #8858371 - Flags: review?(masayuki)
Comment on attachment 8858371 [details] [diff] [review]
patch

> static int sTouchInputActiveState = -1; // 0 mouse, 1 touch, -1 unset

Why don't you create an enum in this method like:

enum
{
  eUnset,
  eMouse,
  eTouch
};

?
Attachment #8858371 - Flags: review?(masayuki) → review+

Updated

2 months ago
Priority: P2 → P1

Updated

2 months ago
Status: NEW → ASSIGNED
(Assignee)

Comment 10

2 months ago
(In reply to Masayuki Nakano [:masayuki] from comment #9)
> Comment on attachment 8858371 [details] [diff] [review]
> patch
> 
> > static int sTouchInputActiveState = -1; // 0 mouse, 1 touch, -1 unset
> 
> Why don't you create an enum in this method like:
> 
> enum
> {
>   eUnset,
>   eMouse,
>   eTouch
> };
> 
> ?

Didn't seem worth it, but no worries, I'll add it. Thanks for the review.
(Assignee)

Comment 11

2 months ago
Created attachment 8859216 [details] [diff] [review]
patch
Attachment #8858371 - Attachment is obsolete: true
Attachment #8859216 - Flags: review+
(Assignee)

Updated

2 months ago
Keywords: checkin-needed
(Assignee)

Updated

2 months ago
Keywords: checkin-needed
(Assignee)

Comment 12

2 months ago
Created attachment 8859220 [details] [diff] [review]
patch

- removed some windows line endings
Attachment #8859216 - Attachment is obsolete: true
Attachment #8859220 - Flags: review+
(Assignee)

Updated

2 months ago
Keywords: checkin-needed

Comment 13

2 months ago
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f4c35ddb1d07
Fire observer events informing front end about changes in input method (touch vs. pointer input). r=masayuki
Keywords: checkin-needed

Comment 14

2 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/f4c35ddb1d07
Status: ASSIGNED → RESOLVED
Last Resolved: 2 months ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55

Updated

2 months ago
Iteration: --- → 55.4 - May 1
You need to log in before you can comment on or make changes to this bug.