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.

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?

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?

(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.

I hope you don't mind me bumping the priority here since this blocks two P2 bugs.

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 }; ?

(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.

- removed some windows line endings

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