User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11 Steps to reproduce: I tried to detect if a visitor is using a touchscreen on his Windows 8 device. But Firefox doesn't detect if the user has a touchscreen and doesn't report it in the useragent. Internet Explorer 10 does have this detection build in. Since Windows 8 is now available and tabletdevices with Windows 8 are being sold now, it it's important that publishers can detect if the user is using a tabletdevice or a computer with a touchscreen the browsers need to supply that information. Actual results: The default useragent string was supplied but no word on the touchscreen. Expected results: Firefox should at the word touch or tabletdevice to the useragent if a touchscreen is detected. What steps will reproduce the problem? 1. Take a PC with a touchscreen or an external monitor with touch. 2. Go to: http://www.adopstools.com/?section=tools&page=browser 3. In the useragent IE10 will mention if a touchscreen is detected so publishers can adjust their website accordingly. Chrome and Firefox don't do that, but they should. Since touchscreens will become more populair in Windows 8. What is the expected result? Firefox should put Touchscreen or tablet device in the useragent if the device has a touchscreen.

This is not the same as bug 773355. That bug is about replacing "Tablet" with "Touch" in the UA. This bug is about adding some word (Presumably "Tablet", if we are sticking with that) to the UA on a touch device such as a Windows 8 tablet. Gerv

I think you should use Touch. Since there are many sort of devices that use touchscreens. Smartphones, Tablets, Hybrid/Smart PC's, All-in-One computers and also notebooks. A lot of notebooks will get a touchscreen with the arrival of Windows 8.

At the very least we should add "Tablet" to the UA on Windows 8 tablets; this is consistent with the decisions made in bug 671634 and documented in https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference It's less obvious what we should do on other touch-enabled form factors, including touch-screen desktops, touch-screen notebooks, and various types of convertible tablet/notebook devices with removable or foldable keyboards. Some options: (1) Include "Tablet" in the UA on any large touch-screen device, including desktops, notebooks, and convertibles. (2) Include "Tablet" in the UA for devices with no built-in keyboard and/or mouse, and use the normal desktop Firefox user-agent for touch-screen devices that also have a keyboard/mouse. (3) Include "Tablet" in the UA for devices with no built-in keyboard and/or mouse, and add an additional token like "Touch" on all touch-screen devices. (4) Include a new token like "Touch" in the UA on all touch-screen devices, and stop using "Tablet" completely. (This is bug 773355.) If we choose options 2 or 3, then we also need to specify how the UA changes on convertible or dockable tablet/noteboook devices whose form-factor can change dynamically. Also, we need to decide whether to apply these changes only to the touch-friendly "Metro" Firefox UI that is designed for touch-screen use, or to both the "Metro" and "desktop" Firefox UI.

Here's my personal suggestion, and the reasoning behind it. ASSUMPTIONS: A. The UA header is used mainly by sites that serve very different content to different devices. Sites that use the same basic UI for both mouse and touch usually serve a single version of their content that works with both types of input, and use feature detection or media queries to determine device capabilities when needed. B. For any site that serves significantly different content to "desktop" and "mobile" users, some portion of users will disagree with the site's default (no matter which version is the default) and will want to switch to the other version. C. Users of touch-screen devices will sometimes interact with the device primarily through touch, and sometimes interact primarily with a mouse / trackpad / other "precise" pointer device. (Some users will stick to one interaction type all the time, while others may switch back and forth even on the same device.) D. *Most* people will prefer the touch-friendly "Metro" Firefox UI while they are interacting primarily through touch, and *most* people will prefer the mouse-friendly "desktop" Firefox UI while they are interacting primarily with precise pointer devices. E. Many web developers will test on only one or two device types. More variations in the User-Agent header would mean more developers who mishandle some of those variations without realizing it. PROPOSAL: * We should add "Tablet" to the User-Agent header when the the Metro Firefox UI is used *and* the hardware supports touch input. * For non-touch hardware, we should make no changes to the User-Agent header. * For the classic (desktop) Firefox UI, we should make no changes to the User-Agent header. PROS: * Users who browse in the mouse-friendly Windows desktop environment will see no changes in content. In particular, users of touch-compatible desktops or notebooks who nonetheless prefer the traditional "desktop" environment style will see familiar desktop-style web content. * Users who browse in the touch-friendly Windows "Metro" environment are likely to get touch-optimized content by default. * Sites are unlikely to serve touch-only content to users without touch hardware. * Users have an easy and (somewhat) intuitive way to choose between the "tablet" and "desktop" versions of sites, for example by using Metro Firefox's "View in desktop" command. * Sites that follow our existing guidelines to send tablet-optimized content to Firefox for Android tablets will not need any changes, and will immediately begin serving tablet-optimized content to Firefox for Metro. CONS: * "Tablet" is not widely used by other browser vendors. "Touch" would be consistent with Internet Explorer. * "Tablet" is kind of misleading since it refers to a specific form factor and is not accurate for all devices where people use our touch UI. "Touch" might look more "right", and be more self-documenting. For example, some authors might wrongly assume "Tablet" implies a certain screen size. QUESTIONS: Q. Why "Tablet" and not "Touch"? Mainly for consistency with our current UA header, especially on Android. Using both "Tablet" and "Touch" would complicate our UA, adding more variations and more chances for authors to make errors. Switching from "Tablet" to "Touch" would undo some of our evangelism work over the past year, and would involve a transition where both variations exist, again complicating web development and testing. However, I think this is a reasonable question to discuss in bug 773355, and I believe the rest of this proposal would still make sense if we replaced "Tablet" with "Touch" everywhere. Q. What about users who want to use desktop Firefox *and* interact with web pages through touch? Ideally, most web developers would use feature detection instead of UA sniffing, and serve a single page to all browsers with good support for both touch and mouse interaction. For sites that do use UA sniffing, the best we can do is help developers choose defaults that work best for the majority of users. Users who dislike the default can easily change it by switching between Metro and desktop Firefox, or by using an add-on or hidden pref to change the UA header.

For reference, I also submitted this bug to Google for the Chrome browser. This browser also lacks detection for touchscreens on Windows 8. That bug can be found here: http://code.google.com/p/chromium/issues/detail?id=159807 Reason for placing the link is that I think it would be a wise thing if all browser manufacturers use the same method and keywords. Internet Explorer 10 is using the keyword 'Touch' in the useragent string in both the Modern UI (Metro) as the classic ui (desktop) when a touchscreen is detected. This works on both tablets, notebooks as desktop computers that are connected to a LCD touchscreen monitor. So I think it would be a wise thing if Mozilla added the keyword touch to the useragent string when a touchscreen is detected. In both the Modern UI as desktop version of Firefox. Using a keyword like tablet doesn't make sense on a notebook with touchscreen. Why I think it's important that touch will be added to the useragent?: In my personal opinion websites need to make two versions of their website. One for smartphones and one for desktop, notebooks and tablets. You can say one for small screens and one for large screens. If you want to create a website that works great on both notebooks and tablets with or without touch you need to know if the device has a touchscreen. For example if you have a mouseover effect in your website, you need to change that for tablets, for example to onClick. Real examples where you need this are: dropdown menu's, lightview images or maybe even hyperlinks that respond to mouseover.

(In reply to Coen from comment #6) > If you want to create a website that works great on both notebooks and > tablets with or without touch you need to know if the device has a > touchscreen. For example if you have a mouseover effect in your website, you > need to change that for tablets, for example to onClick. We generally feel these use cases are properly solved by feature detection and/or media queries.

Hi Matt, I'm afraid I failed to CC myself on this bug, and therefore just wrote up a reopening of this question for mozilla.dev.platform without taking into account your detailed work above. Apologies for that. Perhaps you might like to tweak your position and repost it there? Gerv

I posted my suggestion to the dev-platform thread.

Adding to mvp list, but only so that we make a final decision.

The decision here after the public discussion was not to add anything to the UA (and, in fact, to remove the current Tablet token, bug 829596). If we start to run into significant compatibility problems we may need to revisit this decision, but our current position is that a variety of devices may have touch support, which may even appear and disappear dynamically, and the best thing for sites to do is ask the browser using feature detection what capabilities it has. Gerv

Thanks for the final word, Gerv. We'll revisit in a new bug if the time ever comes.