Closed Bug 1015872 Opened 10 years ago Closed 9 years ago

User Agent string for TVs

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jcheng, Unassigned)

References

Details

(Keywords: dev-doc-complete) 

let's use this bug to start the discussion on what the User Agent Strings should be like for TVs (powered by Firefox OS)
I think the answer here depends a lot on what the default rendering behavior will be.

In my experience, the Web works the best on an 1920 by 1080 TV in Gecko when the device pixel ratio is 1.85. (The desktop Web is generally designed to work in setting where the view port is 1024 CSS pixels wide and break if the view port is narrower.)

If the idea is to ship with a device pixel ratio of 1.85, then we'd probably get the best results by choosing a UA string that sniffs as desktop rather than a UA string that looks too mobile.
Maybe Hallvord and Karl have prior experience of this issue.
When reviewing mobile and tablet UAs for Firefox OS we conducted a survey of existing UAs in the field. Do we have any information about existing TV UAs and, if not, I would suggest that we conduct a survey to see if there is any commonality.
As usual this is a mess.

Media queries are an issue for TVs which have potentially identical media features, including resolution, to some monitors, but different type of navigation such as spatial navigation (with the remote) instead of mouse. Also you need larger fonts in many cases, because the screen is further away and the angular size is similar to a mobile screen.
http://la-grange.net/2012/02/13/mobile-tv


# Google TV
https://developers.google.com/tv/faq#useragentstring

## Recommended by Google

* on Jellybean Android 4.2.2
  Mozilla/5.0 (Linux; Android 4.2.2; <Build Tag>) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1480.0 Safari/537.36

* before Jellybean 
  Mozilla/5.0 (Linux; GoogleTV 4.0.4; <Build Tag>) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.77 Safari/534.24

## In the wild by vendors

* Sony Bravia
  Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Large Screen Safari/533.4 GoogleTV/ 162671

* Logitech Revue
  Mozilla/5.0 (X11; U: Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Large Screen Safari/533.4 GoogleTV/b39389

# Apple
  User-Agent: iTunes-AppleTV/4.1


# Opera TV
  Opera didn't have a specific User agent string (if I remember correctly) apart probably the name of the devices inside the string.
  Also the Opera TV SDK 3 years ago didn't support the TV media type.

* Philips NetTV 
  Opera/9.80 (Linux mips ; U; HbbTV/1.1.1 (; Philips; ; ; ; ) CE-HTML/1.0 NETTV/3.1.0; en) Presto/2.6.33 Version/10.70


# Samsung 
  using SmartTV
  Mozilla/5.0 (SmartHub; SMART-TV; U; Linux/SmartTV) AppleWebKit/531.2+ (KHTML, Like Gecko) WebBrowser/1.0 SmartTV Safari/531.2+



Also http://www.brettjankord.com/2012/02/09/tv-category-added-to-categorizr/
We should also consider game console browsers which are becoming more common.

#Xbox One
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; Xbox; Xbox One)

#PS4
Mozilla/5.0 (PlayStation 4 1.51) AppleWebKit/536.26 (KHTML, like Gecko)

Source and more consoles: http://console.maban.co.uk/
Hmm. Looking at all the above:

* Google is moving away from having GoogleTV identify as GoogleTV; the latest UA string basically just says "this is an Android tablet" (see https://developer.chrome.com/multidevice/user-agent - phones have a Mobile token; this UA doesn't).

* The "in the wild" strings for Google TV are just the earlier form of their recommended UA from the page linked.

* Apple TV is its own special snowflake.

* The Categorizr post is depressing on so many levels. But the main one is that he says "Hey, I'm detecting TVs using all these vendor strings", and hasn't added a string like "TV" so products from other vendors can trip the test even if they wanted to.

Our current B2G phone UA is:

Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0

Seems like we have the following choices:

* Pretend it's a desktop (no OS token)
* Pretend it's a tablet ("Tablet" token)
* Pretend it's a phone ("Mobile" token)
* Create a new TV category ("TV" token)

Both "Mobile" and "Tablet" sort of imply a touch interface. (Again, we see the problem of using the UA to define device types rather than capabilities. <sigh>. MS got this one right.)  

Do we know the answer to Henri's question about device pixel ratios? I am leaning towards using a desktop UA and using things like that to make sure the fonts are big enough.

Gerv
I assume this still needs deciding?

We need to know what device pixel ratio they plan to ship the TV with.

Gerv
Patrick, 

do you have any opinions about the less painful option? ;)
Flags: needinfo?(redux)
Just on the topic of UA string, I think having your regular B2G UA but replacing "Mobile" with "TV" would possibly be best - unless you then start seeing weird compat issues.

On the topic of viewport etc, I've been meaning to write an article about the current state of affairs for ages - but it's still only rough notes. tl;dr: current "web on TV" solutions are indistinguishable from desktop, they usually run at 1280x720 (and a few browsers even go so far as 1920x1080 which is ridiculously small). the common assumption from TV OEMs etc is "people will make a special version of their site for our device with extra-large fonts"...which is rather optimistic for open web sites (versus walled garden environments like HbbTV, Opera TV Store, etc).

For ages, my suggested option has been:

- support width=device-width
- choose an ideal viewport that is most suited (based on CSS reference pixel calculation)

See http://patrickhlauke.github.io/web-tv/ideal-viewport/ for a rough idea

In practice, this means that for most medium-sized HDTVs, the actual viewport should be something similar to a small tablet.

This way, you'd get the best of both worlds: any sites that want to do a TV-specific version should browser-sniff (so you need to ask them to include your UA string in their detection, see also Device Atlas and co) and then redirect to their special "big fonts" version. If a site - most likely - DOESN'T do a special TV version but uses RWD techniques, including width=device-width, your browser will get the small/medium tablet version, which should work well (or rather, better than the default desktop view). Only caveat: sites that make stupid assumptions and use "smaller viewport" to mean "it must be a phone/tablet with touch"...but that's another compat story vs devs making erroneous assumptions.
Flags: needinfo?(redux)
(In reply to Patrick H. Lauke from comment #9)
> Just on the topic of UA string, I think having your regular B2G UA but
> replacing "Mobile" with "TV" would possibly be best

Why? I'm not sure you've explained why a site would need to know that it's being viewed on a TV.

If we can persuade the manufacturers to use a sensible device-pixel ratio, why would the desktop site not be suitable?

> This way, you'd get the best of both worlds: any sites that want to do a
> TV-specific version should browser-sniff (so you need to ask them to include
> your UA string in their detection, see also Device Atlas and co) 

Why would we want to go this route? History shows it to be very painful.

What would a "TV-specific" version of a website do differently?

Gerv
(In reply to Gervase Markham [:gerv] from comment #10)
> Why? I'm not sure you've explained why a site would need to know that it's
> being viewed on a TV.
> 
> If we can persuade the manufacturers to use a sensible device-pixel ratio,
> why would the desktop site not be suitable?

All things being equal, no, it shouldn't make a difference, and the browser could identify as on desktop (i.e. with no "Mobile" or "TV" or similar qualifier).
 
> Why would we want to go this route? History shows it to be very painful.

Web on TV is already a painful space. It depends if you want to target those sites that, for whatever their reason, have decided to make a separate TV version.

> What would a "TV-specific" version of a website do differently?

Web on TV is similar to the mobile web of about 10 years ago. Some complex sites, instead of making their general web presence uncluttered and responsive, opt for UA sniffing and redirecting to a "cut down"/"TV friendly" site. By not identifying any differently than desktop, you will end up just being served the desktop version. Which is probably fine in most cases...again, this will otherwise become a web compat issue on a site-by-site basis (don't have a list of sites that do this sort of thing off-hand, but I do remember from my days doing Opera TV stuff that this practice is sadly still the norm - particularly because practically all Web on TV browsers nowadays DON'T set a sensible viewport/sensible dpr...so a chicken and egg problem).

Now, I don't know the specifics of what you folks plan to do in terms of controls, but another aspect where sniffing for "TV" is used, even if it is a single site rather than a separate "for TV" one: if it smells like a TV, implement keyboard controls (cursor up/right/down/left and enter) and do programmatic focus handling. But if your solution is using some form of on-screen/virtual cursor, this may not be relevant.
Thanks a lot Patrick.
Hallvord, do you think we could experiment some user agent strings, for example one with s/Mobile/tv/, on the full list of Web sites we have in our bank already. We may notice some differences (or not). That may give us a first hindsight if we need to do more analysis or not.
Flags: needinfo?(hsteen)
I think we should be working with any vendors we are doing TV stuff with, to make sure they configure Gecko right such that desktop sites work great, including with a usable input method. And if we do that, which we need to do anyway because many sites only have a desktop version, then there's no reason not to use the Desktop UA everywhere.

Gerv
(In reply to Gervase Markham [:gerv] from comment #13)
> then there's no
> reason not to use the Desktop UA everywhere.

Related, though, this ideal should also hold for mobile (i.e. the browser shouldn't need to identify as "Mobile" if it could be configured to work great for all desktop sites even on a mobile/tablet device). 

The reality though - as with mobile - is that some sites simply do weird stuff based on UA string (and Web on TV has a particularly long-lasting legacy of this, as even to this day the suggested approach is to UA sniff - see for instance https://developers.google.com/tv/web/docs/implement_for_tv#architecture and similar guides).

So the answer to the question "Why would we even want to have a 'TV' identifier and not just pretend to be desktop?" is the same as "Why does our mobile version still need the 'Mobile' identifier?"

Perhaps the answer is just "for stats", and that's another possible requirement?

But again, that's one for web compat to untangle.

Getting back to the viewport/dpr, I would strongly suggest that you do start with an assumption of, say, dpr of 1.85 (which on an HDTV translates to a viewport of approx 1040x585, close to the CSS reference pixel dimensions for a 50" HDTV at the classic 10' viewing distance http://patrickhlauke.github.io/web-tv/ideal-viewport/) but then stress to manufacturers that, if possible, they should choose an ideal viewport/dpr that works great based on their hardware resolution (HDTV, 4K, 8K?) and physical screen dimensions (if they are integrating this directly in a TV of a known dimension to them). For STBs, it may be a good idea for them to also start with an assumption but have a step in the user-guided setup (for instance, Google TV setup lets user manually set safe areas...conceivably, it could also include a "pick the text size that's most comfortable for you" and use that as a guide on what the dpr should be).

Anyway, I'm ranting on one of my pet subjects. Happy to bounce more ideas around re the viewport stuff though, as that's an area I had far too many painful discussions with OEMs already...
(In reply to Patrick H. Lauke from comment #14)
> Related, though, this ideal should also hold for mobile (i.e. the browser
> shouldn't need to identify as "Mobile" if it could be configured to work
> great for all desktop sites even on a mobile/tablet device). 

I don't think this analogy holds. Mobile devices also have significantly different input types (touch and voice), and smaller screens (as in, they cover less of the visual field when held at the normal distance). A TV is perfectly capable of displaying desktop sites if configured correctly; a mobile phone will always struggle. 

> gh - as with mobile - is that some sites simply do weird
> stuff based on UA string (and Web on TV has a particularly long-lasting
> legacy of this, as even to this day the suggested approach is to UA sniff -
> see for instance
> https://developers.google.com/tv/web/docs/implement_for_tv#architecture and
> similar guides).

So perhaps the best solution is to not let them do that, by not revealing that you are a TV.
 
Gerv
(In reply to Gervase Markham [:gerv] from comment #15)
> I don't think this analogy holds. Mobile devices also have significantly
> different input types (touch and voice),

This is also true for TVs that do not provide a virtual cursor and instead rely on d-pad style navigation (either just sending keyboard events, requiring the site to include specific onkeydown/onkeypress handling, or doing special stuff like Opera's old spatnav, which applied heuristics to move its own special focus rectangle around focusable/actionable elements). I take it Firefox's plan is to have a virtual cursor though, right?

> and smaller screens (as in, they
> cover less of the visual field when held at the normal distance).

At the same normal distance (10') a regular-sized tv (30"-40") covers roughly the same visual field as a large mobile phone/small tablet held at "normal" distance too. So issue is almost exactly the same, and the solution just for layout is the same: start off with a sensible-ish viewport (e.g. how mobiles settle on starting with roughly 800-900 pixel wide when held in portrait), but react to width=device-width and implement a better ideal viewport that's close enough to the CSS reference pixel definition.

Again, I'm not trying to be difficult, and laud the idea that TV should not identify as anything other than desktop. Just be wary of legacy pages/sites.
(In reply to Karl Dubost :karlcow from comment #12)
> Hallvord, do you think we could experiment some user agent strings,

Sure - what about running through all the sites we track on arewecompatibleyet.com comparing these user-agents:

Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Mozilla/5.0 (TV; rv:30.0) Gecko/30.0 Firefox/30.0

Sounds good? I suppose I can get that done over the weekend or something.
Flags: needinfo?(hsteen)
Seif, what do you think of this? Perhaps an interesting test for your new infrastructure to do a one-off report of differences found (if any) for these two UAs?
Additionally maybe also worth adding a common TV one already in the wild (for instance the Sony Bravia one, or Google TV) into the mix, to test if sites do UA sniff for that specific one (and then, if high profile enough, exploring how they do it - e.g. device atlas or similar - and evaluating if it's worth doing something about it)?
(In reply to Hallvord R. M. Steen from comment #17)
> (In reply to Karl Dubost :karlcow from comment #12)
> > Hallvord, do you think we could experiment some user agent strings,
> 
> Sure - what about running through all the sites we track on
> arewecompatibleyet.com comparing these user-agents:
> 
> Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
> Mozilla/5.0 (TV; rv:30.0) Gecko/30.0 Firefox/30.0
> 
> Sounds good? 

I don't think anyone's suggesting using the Mobile UA, are they? The two to compare would be a desktop UA and a TV UA. Hmm... what OS/platform would one put in a "Desktop" UA here?

Gerv
> > Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
> > Mozilla/5.0 (TV; rv:30.0) Gecko/30.0 Firefox/30.0

> I don't think anyone's suggesting using the Mobile UA, are they? The two to
> compare would be a desktop UA and a TV UA. Hmm... what OS/platform would one
> put in a "Desktop" UA here?

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/30.0 Firefox/30.0

/ducking, running and hiding :-p
(In reply to Patrick H. Lauke from comment #14)
> Getting back to the viewport/dpr, I would strongly suggest that you do start
> with an assumption of, say, dpr of 1.85 (which on an HDTV translates to a
> viewport of approx 1040x585, close to the CSS reference pixel dimensions for
> a 50" HDTV at the classic 10' viewing distance

I think 1.85 dpr is the right way to go (for 1920x1080 screen; multiply by two for 4K screens), but not because of the CSS reference pixels but because that's the highest dpr you can you that doesn't break typical desktop Web layouts when the view port width in device pixels is 1920.

Are we going for that default dpr for B2G on TVs? Again, it doesn't make sense to establish the UA string before establishing the dpr.
(In reply to Henri Sivonen (:hsivonen) from comment #22)
> I think 1.85 dpr is the right way to go (for 1920x1080 screen; multiply by
> two for 4K screens), but not because of the CSS reference pixels but because
> that's the highest dpr you can you that doesn't break typical desktop Web
> layouts when the view port width in device pixels is 1920.

As a default, I'd agree you want whatever yields the least breakage (similar to what, say, mobile devices do settingly on a 900ish width viewport).

However, when the page also specifies width=device-width, I'd argue that it should be whatever comes closest to the CSS ref pixel, making it dependent on physical size of the screen and taking into account average 10' experience. The assumption being that a site that defines viewport this way is not just designed for desktop, but has some form of responsive/adaptive design going which would work fine on a TV (e.g. a 30" TV may end up having an ideal viewport that triggers the "tablet" CSS styles, which should be very adequate). Of course, this assumes that devs didn't make weird assumptions a la "if viewport is below this size, it must be a touchscreen device so I'll just listen to touch events"...but that's another world of pain.

> Are we going for that default dpr for B2G on TVs? Again, it doesn't make
> sense to establish the UA string before establishing the dpr.
(In reply to Henri Sivonen (:hsivonen) from comment #22)
> I think 1.85 dpr is the right way to go (for 1920x1080 screen; multiply by
> two for 4K screens), but not because of the CSS reference pixels but because
> that's the highest dpr you can you that doesn't break typical desktop Web
> layouts when the view port width in device pixels is 1920.

As a default, I'd agree you want whatever yields the least breakage (similar to what, say, mobile devices do settingly on a 900ish width viewport).

However, when the page also specifies width=device-width, I'd argue that it should be whatever comes closest to the CSS ref pixel, making it dependent on physical size of the screen and taking into account average 10' experience. The assumption being that a site that defines viewport this way is not just designed for desktop, but has some form of responsive/adaptive design going which would work fine on a TV (e.g. a 30" TV may end up having an ideal viewport that triggers the "tablet" CSS styles, which should be very adequate). Of course, this assumes that devs didn't make weird assumptions a la "if viewport is below this size, it must be a touchscreen device so I'll just listen to touch events"...but that's another world of pain.

> Are we going for that default dpr for B2G on TVs? Again, it doesn't make
> sense to establish the UA string before establishing the dpr.
and to clarify (apologies for that double comment above, not quite sure how that happened) i'm thinking of a variable dpr purely for future-proofing, as actual sizes of displays can and will vary greatly (in a similar way that dpr for mobile devices is not generally hardcoded, but varies on a per-device basis)
So to summarise, I think we should use a "Desktop" style UA to get desktop content, and it would look like this:

Mozilla/5.0 (rv:18.0) Gecko/18.0 Firefox/18.0

So no Mobile, Tablet or TV tokens.

Gerv
See Also: → 1199592
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1199592#c42, this bug can probably be fixed. The decision for the TV emulator was:

"Mozilla/5.0 (TV; rv:44.0) Gecko/44.0 Firefox/44.0" 

I suggest we close this and use the same for TV.

Joe, I don't know if there's any further actions needed for this bug, or if it was just for discussion.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(jcheng)
Keywords: dev-doc-needed
Resolution: --- → FIXED
thanks. yup this is just for discussion. let's close it
Flags: needinfo?(jcheng)
Confirmed that the article at https://developer.mozilla.org/en-US/docs/Web/HTTP/Gecko_user_agent_string_reference has been updated with this information.
You need to log in before you can comment on or make changes to this bug.