Closed Bug 1344907 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Widget: Win32, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla55
Iteration:
55.4 - May 1
Tracking Status
firefox55 --- fixed

People

(Reporter: mconley, Assigned: jimm)

References

Details

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

Attachments

(1 file, 2 obsolete files)

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.
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.
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)
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
No longer blocks: photon-visual
Whiteboard: tpi:+ → [photon] tpi:+
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)
Flags: needinfo?(dao+bmo)
Whiteboard: [photon] tpi:+ → [photon-visual][tpi:+]
Blocks: 1355771
(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: photon-touch
Flags: needinfo?(shorlander)
Blocks: 1256754
I hope you don't mind me bumping the priority here since this blocks two P2 bugs.
Priority: P3 → P2
Flags: qe-verify-
Attached patch patch (obsolete) — Splinter Review
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+
Priority: P2 → P1
Status: NEW → ASSIGNED
(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.
Attached patch patch (obsolete) — Splinter Review
Attachment #8858371 - Attachment is obsolete: true
Attachment #8859216 - Flags: review+
Keywords: checkin-needed
Keywords: checkin-needed
Attached patch patchSplinter Review
- removed some windows line endings
Attachment #8859216 - Attachment is obsolete: true
Attachment #8859220 - Flags: review+
Keywords: checkin-needed
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
https://hg.mozilla.org/mozilla-central/rev/f4c35ddb1d07
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Iteration: --- → 55.4 - May 1
You need to log in before you can comment on or make changes to this bug.