Exposing (mobile) device info via the user agent or HTTP headers
Benjamin Smedberg
<https://bugzilla.mozilla.org/show_bug.cgi?id=625238>.
In that bug, developers of mobile websites are asking that information
about the specific device being used be made available to websites via
the user agent. They are asking for this for the following reasons:
*
We [want to] have advertisers wanting to target a specific device
*
We may serve different content to a HTC Desire and a Samsung
Galaxy Tab
*
We [want to] have device statistics
*
We [want to] scale images, adapt content, serve video and change
font size depending on
the device and screensize.
* Content providers that have web storefronts for mobile, display
available content depending on the
detected device.
Technically, exposing the device via the UA string allows websites to
use frameworks such as WURFL (http://wurfl.sourceforge.net/) to provide
content customized for various devices. Apparently, the other major
mobile browsers (opera, opera mini, mobile safari, and IE for windows
phone) currently include this device information in the UA string.
I WONTFIXed the bug after consulting with dougt, because I do not
believe that serving content based on device capabilities is a solution
that we should be promoting, and that it will eventually lead to a very
bad/fragmented web for users.
* Device repositories are going to cater to devices with high market
share, leaving users with new, older, and less common devices out
in the dark.
* We want websites to work towards providing common content and
styling it using CSS media queries and other device-sensitive
styling information, so that existing content will automatically
be available to other device factors as they are developed.
* Websites which customize content based on device characteristics
are extremely bad for testing, especially on new devices.
* Exposing device information adds several bit of entropy for
unwanted user tracking.
I am now getting a lot of pushback in the bug from web developers who
are using WURFL or similar libraries and believe that we are just
shooting our users is the foot by not providing the information that
they want (need) to customize their site per-device.
Please discuss:
* What principles should we use to make this decision?
* Is there other information that we can expose which would solve
most author problems without being strictly device specific? e.g.
screen size, presence or absence of various features such as
keyboard or multi touch screen, etc.
* If we do expose additional information, how much of this
information should be made available via the client side (CSS
media queries, DOM data, etc), and how much needs to be made
available immediately to the server via the UA string and/or HTTP
headers?
--BDS
Armen Zambrano Gasparnian
Upon agreement we would provide the needed data.
Doug Turner
http://blog.mozilla.com/dwitte/2010/08/24/user-agent-string-changes-coming-in-firefox-4/
We have been reducing information in the UA string.
*
*
*
*
Please discuss:
--BDS
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Andy Bajka
Having the device and browser information in the UA allows me to be
able to help my forum members with troubleshooting questions. This is
an important requirement and unless the User Agent provides this
information like all the other mobile browsers do, I would have to
discourage users from using Firefox Mobile.
Thank you.
Gervase Markham
> We [want to] have advertisers wanting to target a specific device
I feel... unmoved.
> We may serve different content to a HTC Desire and a Samsung
> Galaxy Tab
That's not a reason unless it's a disguised form of one of the other
reasons.
> We [want to] scale images, adapt content, serve video and change
> font size depending on
> the device and screensize.
That is a more reasonable request; but these things should be done
in-page, not server-side, and should be based on device-independent
values like screen size.
> I WONTFIXed the bug after consulting with dougt, because I do not
> believe that serving content based on device capabilities is a solution
> that we should be promoting, and that it will eventually lead to a very
> bad/fragmented web for users.
I think you did the right thing.
> * What principles should we use to make this decision?
Exactly the ones you used - what best aligns with our mission to have
one, open web across all access methods?
> * Is there other information that we can expose which would solve
> most author problems without being strictly device specific? e.g.
> screen size, presence or absence of various features such as
> keyboard or multi touch screen, etc.
A complete list of "etc" might help the debate. What features are we
considering exposing?
Screen size can change a lot - if the user rotates, or (on desktop) if
they resize the window. Content has to cope with that dynamically, not
take some cheating server-side best guess shortcut. And you can get this
through the DOM anyway.
Keyboard is irrelevant. If there were devices with no method of text
input whatsoever, we might want to indicate that - but given that those
devices would be unable to interact with much of the existing web, I
doubt they will ever appear.
I can imagine serving a very different UI to multi-touch (or rather,
multi-pointer) screens...
> * If we do expose additional information, how much of this
> information should be made available via the client side (CSS
> media queries, DOM data, etc), and how much needs to be made
> available immediately to the server via the UA string and/or HTTP
> headers?
The privacy point is a good one. UAs can, at least in theory, detect if
their interfaces are being strip-mined for identifying data. But if you
send it to the server, you have no idea what they are doing with it. So
I'd say that someone would need to make a very, very good case to put
something in the UA string.
Gerv
Doug Turner
Thank you for your comments. Discovering more information about your user's devices via the UA string so that you can troubleshot problems as a moderator is an interesting use case. What specific bits of information do you actually need to troubleshoot the issues you are seeing?
We tend to think that adding more information to the UA continues to fragment the web. We also tend to think that it is a potential privacy leak (search for Panopticlick).
Doug
Hi Benjamin,
Thank you.
_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Shawn Wilsher
be faking it. This use case is exactly why we created about:support,
although we don't include the device type on mobile this wouldn't be
difficult to add.
Cheers,
Shawn
Paul Biggar
>> We may serve different content to a HTC Desire and a Samsung
>> Galaxy Tab
>
> That's not a reason unless it's a disguised form of one of the other
> reasons.
I would guess that they would like to distinguish between phones and
tablets. This seems the most compelling of the arguments (having used
an iphone and an ipad, they do feel different and require different
UIs). I suspect detecting screen size would work here.
--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
Mike Hommey
> On Fri, Apr 1, 2011 at 9:39 AM, Gervase Markham <ge...@mozilla.org> wrote:
> >> Galaxy Tab
> >
> > That's not a reason unless it's a disguised form of one of the other
> > reasons.
>
> tablets. This seems the most compelling of the arguments (having used
> an iphone and an ipad, they do feel different and require different
> UIs). I suspect detecting screen size would work here.
Both screen size in pixels and inches (or dpis) would be useful.
Mike
Shawn Wilsher
> I would guess that they would like to distinguish between phones and
> tablets. This seems the most compelling of the arguments (having used
> an iphone and an ipad, they do feel different and require different
> UIs). I suspect detecting screen size would work here.
Cheers,
Shawn
Paul Biggar
> On 4/1/2011 10:08 AM, Paul Biggar wrote:
>>
>> I would guess that they would like to distinguish between phones and
>> tablets. This seems the most compelling of the arguments (having used
>> an iphone and an ipad, they do feel different and require different
>> UIs). I suspect detecting screen size would work here.
>
> This is what CSS media queries [1] are design for though, right?
I read the abstract, and I don't think so. I believe one would want to
create quite different apps based on the form factor (think games, not
web pages), not just have different CSS. However, I know very little
here, so I can't argue definitively.
Doug Turner
I tend to think that it's "one web". I don't think that we should advocate that people write a game or a website so that it only works on one phone or one screen size, or only if it supports a web content feature, like offline-storage.
----- Original Message -----
From: "Paul Biggar" <pbi...@mozilla.com>
To: "Shawn Wilsher" <sdw...@mozilla.com>
Cc: dev-pl...@lists.mozilla.org
Sent: Friday, April 1, 2011 10:22:59 AM
Subject: Re: Exposing (mobile) device info via the user agent or HTTP headers
Mark Finkle
> On Fri, Apr 1, 2011 at 10:17 AM, Shawn Wilsher <sdwi...@mozilla.com> wrote:
> > On 4/1/2011 10:08 AM, Paul Biggar wrote:
>
> >> I would guess that they would like to distinguish between phones and
> >> tablets. This seems the most compelling of the arguments (having used
> >> an iphone and an ipad, they do feel different and require different
> >> UIs). I suspect detecting screen size would work here.
>
> > This is what CSS media queries [1] are design for though, right?
>
> I read the abstract, and I don't think so. I believe one would want to
> create quite different apps based on the form factor (think games, not
> web pages), not just have different CSS. However, I know very little
> here, so I can't argue definitively.
I think very "different apps" could be handled by different URLs. Why
have one URL try to do everything? We see major web properties using
different URLs for mobile version of their websites.
Web clients can also delay load chunks of content and JS based on
screen size. CSS media queries can be used to auto-request the right-
sized images as well.
L. David Baron
> On Fri, Apr 1, 2011 at 10:17 AM, Shawn Wilsher <sdw...@mozilla.com> wrote:
> > On 4/1/2011 10:08 AM, Paul Biggar wrote:
> >>
> >> I would guess that they would like to distinguish between phones and
> >> tablets. This seems the most compelling of the arguments (having used
> >> an iphone and an ipad, they do feel different and require different
> >> UIs). I suspect detecting screen size would work here.
> >
> > This is what CSS media queries [1] are design for though, right?
>
> I read the abstract, and I don't think so. I believe one would want to
> create quite different apps based on the form factor (think games, not
> web pages), not just have different CSS. However, I know very little
> here, so I can't argue definitively.
We have a bug on exposing media queries to JavaScript as well:
https://bugzilla.mozilla.org/show_bug.cgi?id=542058
I have about a quarter of a patch for this in my tree; I've been
meaning to write the rest.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Andy Bajka
You said the Operating System and Browser type will be included in the
User Agent. Will the browser type differentiate between the Firefox
and Firefox Mobile?
Thank you.
Matt Brubeck
Andy Bajka
> Yes, the string "Fennec/" in the User-Agent header means that the browser is Firefox for mobile.
Great in that case I'm happy. Sorry I misunderstood the original post
as implying that the User Agent would only show Firefox and not
distinguish between the Firefox and Firefox Mobile.
Thank you.
anders
And let me ask you a simple question. Would it be ok for iPhone and
iPad to have the same UA? (I think you know the answer)
And then have a look at Android. We have small screen devices (240px)
and tablets up to 1024px. You have Blackberry Playbook Tablet that is
going to run Android. Google TV has Android. Android is even going to
be used in cars. They would run the same browser but the context is
completely different. The world is fragmented. Taking deviceinfo out
of the UA is not going to make the world less fragmented, but more
fragmented because you will be the only browser that does this.
Device != Browser
regards
Anders / @amaMobile
Robert O'Callahan
> We have a bug on exposing media queries to JavaScript as well:
> https://bugzilla.mozilla.org/show_bug.cgi?id=542058
>
> I have about a quarter of a patch for this in my tree; I've been
> meaning to write the rest.
>
Please! :-)
Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Robert Kaiser
> In that bug, developers of mobile websites are asking that information
> about the specific device being used be made available to websites via
> the user agent.
Just like the exact version number, this should not be in the UA but in
a JS object that is only exposed after a geolocation-style prompt to the
user, IMHO. Privacy matters.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Doug Turner
What specifically are you interested in? Just the h/w of the screen? It is hard for me to tell what you are asking for.
Doug
----- Original Message -----
From: "anders" <anders.m...@gmail.com>
To: dev-pl...@lists.mozilla.org
Sent: Friday, April 1, 2011 3:16:48 PM
Subject: Re: Exposing (mobile) device info via the user agent or HTTP headers
Device != Browser
regards
Anders / @amaMobile
Doug Turner
see the w3c dap systeminfo draft. probably is exactly what you are interested in.
----- Original Message -----
From: "Robert Kaiser" <ka...@kairo.at>
To: dev-pl...@lists.mozilla.org
Sent: Friday, April 1, 2011 3:36:17 PM
Subject: Re: Exposing (mobile) device info via the user agent or HTTP headers
Robert Kaiser
David E. Ross
> Discussion followup to bug 625238
> <https://bugzilla.mozilla.org/show_bug.cgi?id=625238>.
>
> about the specific device being used be made available to websites via
>
> *
>
>
>
> We may serve different content to a HTC Desire and a Samsung
> Galaxy Tab
>
>
> We [want to] have device statistics
>
> *
>
> font size depending on
> the device and screensize.
>
> available content depending on the
> detected device.
>
> Technically, exposing the device via the UA string allows websites to
> use frameworks such as WURFL (http://wurfl.sourceforge.net/) to provide
> content customized for various devices. Apparently, the other major
> mobile browsers (opera, opera mini, mobile safari, and IE for windows
> phone) currently include this device information in the UA string.
>
> believe that serving content based on device capabilities is a solution
> that we should be promoting, and that it will eventually lead to a very
> bad/fragmented web for users.
>
> share, leaving users with new, older, and less common devices out
> in the dark.
> * We want websites to work towards providing common content and
> styling it using CSS media queries and other device-sensitive
> styling information, so that existing content will automatically
> be available to other device factors as they are developed.
> * Websites which customize content based on device characteristics
> are extremely bad for testing, especially on new devices.
> * Exposing device information adds several bit of entropy for
> unwanted user tracking.
>
> I am now getting a lot of pushback in the bug from web developers who
> are using WURFL or similar libraries and believe that we are just
> shooting our users is the foot by not providing the information that
> they want (need) to customize their site per-device.
>
> Please discuss:
>
> most author problems without being strictly device specific? e.g.
> screen size, presence or absence of various features such as
> keyboard or multi touch screen, etc.
> information should be made available via the client side (CSS
> media queries, DOM data, etc), and how much needs to be made
> available immediately to the server via the UA string and/or HTTP
> headers?
>
>
The Web developers want to sniff for the device type. I thought that
the general philosophy within Mozilla was to discourage sniffing. This
is a good philosophy because Web developers usually sniff incorrectly
(e.g., sniffing for "Firefox" when they should instead sniff for "Gecko").
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Anders
- Video capabilites of the device (video codec, bitrate, aspect ratio,
audio codec, streaming protocol (http or rtsp)
- Our advertisers need to serve correct ads to the device (this could
be based on screensize, android version, hardware properties, or just
a specific device. There are for instance some apps tailored for
Android tablets that advertisers want to market.
- Our advertisers and site owners need to know if the user can sms or
call with the device (not all devices are phones)
- I need to know if it's a touch device, clickwheel or stylus
(different interaction model)
- I need to compress images serverside to send as few bytes as
possible over the wire
And this is just me, Ask around and you will probably get more
practical examples.
Look at how Facebook is approaching this (written yesterday)
http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
There is no way they could rely on "progressive enhancement" and
feature detection to build that site. In 5 years? Mayby, but not now.
-Anders / @amaMobile
> dev-platf...@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-platform
Doug Turner
are you looking for something like "the device id", or a listing of each of these features in various http headers?
Doug,
-Anders / @amaMobile
_______________________________________________
Robert O'Callahan
> - Video capabilites of the device (video codec, bitrate, aspect ratio,
> audio codec, streaming protocol (http or rtsp)
>
HTML5 video deals with content negotiation.
- Our advertisers need to serve correct ads to the device (this could
> be based on screensize, android version, hardware properties, or just
> a specific device. There are for instance some apps tailored for
> Android tablets that advertisers want to market.
>
I'm sure advertisers would like to know everything about the user, but we
aren't going to tell them.
- Our advertisers and site owners need to know if the user can sms or
> call with the device (not all devices are phones)
>
Ditto. We do need an API to let the user initiate a call or SMS from Web
content, though.
> - I need to know if it's a touch device, clickwheel or stylus
> (different interaction model)
>
We need new DOM API to detect what kind of events you can get.
> - I need to compress images serverside to send as few bytes as
> possible over the wire
>
How is that affected by the device? If it's about screen size or density,
CSS media queries cover that.
Look at how Facebook is approaching this (written yesterday)
>
> http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
>
That's a great example of how sniffing is likely to go wrong:
For example, on the latest WebKit based devices, like iPhone and Android, we
> use CSS3 and vendor-specific rules for display and animation as well as some
> of the new JavaScript APIs included in HTML5 for local caching and history
> management. For example, to animate out a deleted comment, all it takes is:
>
> .deletable.deleting { -webkit-transition: translateX(-200%); }
>
If they sniff for "Android" and serve -webkit-transition, that's going to
fail for any non-Webkit browser running on Android. That (sniffing for one
thing and using that to determine behavior for unrelated features) is
exactly the sort of bug we see all the time with UA sniffing, and it will
repeat with device sniffing.
James Pearce
would cost next to nothing to implement this in the same way that
every other browser on the planet ever has, and that the HTTP spec
clearly suggests you should.
A claim that media queries make server-side adaptation unnecessary is
extremely naive, if only for one logical reason: when I dispatch my
resources, how am I going to know that the browser supports media
queries at all if I don't even know what it is?
Other examples: should I be sending the highest resolution of my
images to every device hoping that the browser's CSS will resize them
down to size once (if ever) they get there? Should I send multiple
encodings of a single video to each browser in the hope it will be
able to pick the most suitable one and ignore the others? Should I
even be sending progressively enhancing JavaScript if I don't know
your browser supports it well? (Most mobile browsers still do not).
In all honesty, contemporary server-side recognition (WURFL,
DeviceAtlas etc) is probably far better than you're imagining - it's
not just looking for plain keywords with a broad brush... and the
quality of browser information keyed off these agent strings is
generally very high, fast, and accurate.
"Just telling us 'we need it' is not enough. We think you don't."
... is baffling, and insulting, logic in the bug report. http://phon.me/?p=44
says that one consolation might be your likely lack of traction. I
believe that this decision and arrogance won't help prove him wrong.
On the other hand, you could help the world imagine and build a rich,
responsive, beautiful and clever web which has escaped its homogenous
desktop tethering and document-centric assumptions and which you'll
have been instrumental in helping to bring to life. Given that you're
pretty much the only mobile browser vendor left that doesn't have an
interest in native applications (and therefore no tactical reasons for
throttling your browser's development accordingly), I'd been betting
on you being the ones that would re-seize this vision.
Suffice to say, this isn't a good start.
James
Boris Zbarsky
> I'm more than a little surprised by the idealism here.
Are you? I recommend http://www.mozilla.org/about/ (watch the video).
> I presume it would cost next to nothing to implement this
It would not cost us much in the way of work, no. It would cost our
users something, though, and we would feel that we are selling them out.
> in the same way that every other browser on the planet ever has
No desktop browser I'm aware of being used in any quantity in recent
memory has sent the sort of information that is being asked for here.
If you have data to the contrary, I would love to see it.
> and that the HTTP spec clearly suggests you should.
Oh, c'mon. If you want to get all spec-pedantic here, what the spec
"suggests" (RFC 2616 section 3.8, which is referenced from section 14.43
as the normative section for what goes in this field) is that
applications "identify themselves by software name and version".
Now maybe you're making the argument that in this case the exact
identity of the piece of hardware used is a "subproduct which forms a
significant part of the user agent"? I think that's a bit of a stretch,
personally.
One other note: the RFC in question dates back to 1999 and assumes good
faith on the part of the server. It's been 12 years since then, and
this assumption may or may not be all that justified in light of our
experiences over that time....
> A claim that media queries make server-side adaptation unnecessary is
> extremely naive
I don't have a good feel for the set of server-side adaptations that are
commonly performed, and would love to learn more about them. Is there a
good resource for that?
> if only for one logical reason: when I dispatch my
> resources, how am I going to know that the browser supports media
> queries at all if I don't even know what it is?
You assume that it does, going forward.
In any case, this is a complete and utter straw man. You certainly know
what "Gecko" is and that it supports media queries. It says the "Gecko"
part right in that User-Agent string that we _do_ send, after all.
> Other examples: should I be sending the highest resolution of my
> images to every device hoping that the browser's CSS will resize them
> down to size once (if ever) they get there?
I'll assume this was a non-rhetorical question.
Whether the images get there has nothing to do with the hardware of the
device; it's a property of the network between you and the device. So
exposing the identity of the hardware tells you nothing about whether
the images will get there. Communicating properties of the network to
the server would be great. In fact, communicating them to the _browser_
would be great! We could both optimize better given that information.
I'm very interested in ways we could get that working.
You should in fact assume that the browser's CSS will resize them down
to the size desired. That's a pretty basic CSS thing; having it not
work would be ... surprising.
If you send your images to that phone with a 200px by 300px screen and
resize them server-side to that size and then the user saves the page as
PDF and looks at it on their desktop or prints it you probably end up
with an unhappy user.
> Should I send multiple encodings of a single video to each browser in the hope it will be
> able to pick the most suitable one and ignore the others?
You should tell the browser which encodings you have available and it'll
pick the ones it supports, right? That's how HTML5 <video> works. If
you're talking about encodings in the same format but at different
bitrates, then that's not something that depends on the destination
hardware but rather on the intermediate network. If you're talking
about encodings in the same format at different resolutions, that's why
<source> elements in HTML5 have an attribute called "media" which takes
as its value one of those media queries that people seem to think are
useless So you can explicitly say which video streams to use for
various screen resolutions.
> Should I even be sending progressively enhancing JavaScript if I don't know
> your browser supports it well? (Most mobile browsers still do not).
This is, once again, a strawman. You know the rendering engine, so you
know whether JavaScript is enabled (unless the user has turned it off,
or installed NoScript, or ...).
> In all honesty, contemporary server-side recognition (WURFL,
> DeviceAtlas etc) is probably far better than you're imagining - it's
> not just looking for plain keywords with a broad brush... and the
> quality of browser information keyed off these agent strings is
> generally very high, fast, and accurate.
You may wish to read the thread at
http://lists.w3.org/Archives/Public/www-style/2011Apr/0002.html which is
oddly on-topic here. I have no doubt that your tools give you a wealth
of detailed and correct information! Based on my experiences with
"non-mobile" sites, I have doubts about how that information ends up
being used.
The comments so far in this thread have allayed some of those doubts (in
the sense that people are sounding much more competent than what I tend
to see out there), but strengthened others (in that their goals seem to
be fairly different from mine).
> "Just telling us 'we need it' is not enough. We think you don't."
>
> .... is baffling, and insulting,
No, it's an invitation to convince us that we're wrong. Just telling us
"you're wrong" is not very convincing. Information about the actual
technical issues and why the solutions involved are a good thing for our
users (as opposed to, say, your advertisers) would go much better.
> logic in the bug report. http://phon.me/?p=44
> says that one consolation might be your likely lack of traction.
He also has lots of concerns about low-end devices running UAs with
limited JS capabilities. But if you see a mobile Firefox UA string,
which we DO send, you know:
1) It's not a 2011-era low-end device.
2) It supports JavaScript.
So he too is arguing against the same strawman you have chosen.
> On the other hand, you could help the world imagine and build a rich,
> responsive, beautiful and clever web which has escaped its homogenous
> desktop tethering and document-centric assumptions and which you'll
> have been instrumental in helping to bring to life.
I think we agree that this is desirable.
We happen to think that sending the hardware identifier of the hardware
we're running on is not the right way to get there.
We're open to discussion of what said right way is.
-Boris
Boris Zbarsky
> On 4/2/11 12:27 AM, James Pearce wrote:
>> I'm more than a little surprised by the idealism here.
>
> Are you? I recommend http://www.mozilla.org/about/ (watch the video).
And one other comment, on the idealism angle.
The sense I'm getting is that people are concerned about how to get
their existing body of content rendering well in UAs on phones that are
several years old at this point as well as the new Firefox. Adding the
hardware identifier to our UA is expedient for this purpose, because it
lets all your existing infrastructure "just work".
I think the differences arise from two issues.
First, the comments I've seen make it sound like the infrastructure is
being used in ways that seem harmful to our users, as well as in ways
beneficial to them.
Second, while your focus on the here and now is understandable, we as an
organization are also thinking about how things will look 3 years from
now or more. And from that point of view, adding the hardware
identifier seems actively harmful. This is why we're more interested in
figuring out a solution that will solve your short-term problems while
not creating long-term ones. I understand that this is more work for
you than having us just play along with the established setup, and you
see little benefit for doing that work. You are of course free to take
a "my way or the highway" approach on the issue, as the phon.me post you
cite seems to. But I think that it would be more productive to talk to
us about the specific problems your existing infrastructure is solving.
-Boris
Robert O'Callahan
> I'm more than a little surprised by the idealism here.
You must be new here :-).
But seriously, it's not so much idealism as years of bitter experience with
the failures of UA-sniffing, and a desire to not see those mistakes
repeated.
Kevin Gadd
<jamesg...@googlemail.com> wrote:
> I'm more than a little surprised by the idealism here. I presume it
> would cost next to nothing to implement this in the same way that
> every other browser on the planet ever has, and that the HTTP spec
> clearly suggests you should.
Boris said most of what I have to say here, but I'd like to make an
important point: Adding content to every HTTP request's headers does
not cost 'next to nothing'. And end user's browser makes thousands of
requests every day and you're adding extra weight to all of those
requests that can't be removed. Given that almost every mobile network
charges for bandwidth (or imposes aggressive limits) this bandwidth is
the opposite of free. There's also the question of whether bloating
the HTTP headers could degrade the browsing experience by increasing
the number of TCP packets required for each request.
Given that this information is only used for a small subset of cases,
the potential risks are not justified by the benefits presented thus
far. All the device information being asked for also seems like stuff
that you could query once on the client side using JS, and then send
back to the server - once - reducing the cost of such a feature
significantly. If I were to advocate this kind of device information,
it would be client-side, not in HTTP headers. If you want to generate
device-targeted content on the server, it should be as an optimization
- not as the only way you do it.
Also, sending device information in headers ignores the fact that
every modern smartphone I've used supports display rotation, which
changes the dimensions of the browser. If you're using display size to
customize the content you serve to the browser, your page is going to
break horribly when I rotate my phone.
-kg
Matt Brubeck
> A claim that media queries make server-side adaptation unnecessary is
> extremely naive, if only for one logical reason: when I dispatch my
> resources, how am I going to know that the browser supports media
> queries at all if I don't even know what it is?
See http://yiibu.com/ and this associated presentation for some practical examples of how Media Queries are used to build adaptive mobile sites that still work in legacy browsers with no Media Query support:
http://www.slideshare.net/bryanrieger/rethinking-the-mobile-web-by-yiibu/
(The most relevant point is starting on slide 79: "The absence of support for @media queries is in fact the first @media query.")
> Other examples: should I be sending the highest resolution of my
> images to every device hoping that the browser's CSS will resize them
> down to size once (if ever) they get there?
You can use media queries and JavaScript to determine which image to request and to ensure that only the correct image is downloaded (and yes, you can still provide a fallback that works in browsers without media queries or JavaScript).
> Should I send multiple
> encodings of a single video to each browser in the hope it will be
> able to pick the most suitable one and ignore the others?
You can use the Accept: header to determine server-side which video encoding to use. Anyway, using the name of the hardware device to determine would be incorrect; for example, Firefox and WebKit running on the same device support different audio and video codecs.
> Should I
> even be sending progressively enhancing JavaScript if I don't know
> your browser supports it well? (Most mobile browsers still do not).
Again, this has nothing to do with the current debate about device info in the User-Agent header; adding information about hardware to the Firefox User-Agent header will not tell you anything new about its JavaScript support.
> In all honesty, contemporary server-side recognition (WURFL,
> DeviceAtlas etc) is probably far better than you're imagining - it's
> not just looking for plain keywords with a broad brush... and the
> quality of browser information keyed off these agent strings is
> generally very high, fast, and accurate.
And yet past versions of Firefox that included device information in the User-Agent string were penalized for it, at least as much as they benefitted from it. For example, we included "Nokia N800" in the User-Agent string for old versions of Firefox on Maemo. This caused sites like YouTube to assume that it was some unrelated Nokia N-series browser, and send video content that it couldn't play.
Server-side detection is fine for the default browser on a known device, but it creates a major barrier to entry for brand new browsers (or browsers that are new to a specific device).
Nicholas Nethercote
>
>> in the same way that every other browser on the planet ever has
>
> No desktop browser I'm aware of being used in any quantity in recent memory
> has sent the sort of information that is being asked for here. If you have
> data to the contrary, I would love to see it.
I'm missing some context here. Comments higher up the thread make it
sound like every other mobile browser exposes all this info and
Mozilla is being recalcitrant by not exposing it. Is that true?
Nick
Justin Dolske
> And let me ask you a simple question. Would it be ok for iPhone and
> iPad to have the same UA? (I think you know the answer)
...Yes? The iPhone was around for 3 years before the iPad came out, and
the rest of the web for another decade or two before that. Who'd want to
get an iPad if it was unable to use the web because it was neither a
desktop nor iPhone?
No one doubts that sending more info can be useful for some people
wanting to do some things in certain ways. [Good heavens, can you
imagine the awkwardness of a site recommending a *black* case for my
*white* iPhone?!] The question Mozilla is concerned with is if that's
good or bad for the web in the long run, and if there are other ways of
exposing such data that are less problematic.
Justin
Henri Sivonen
> I'm more than a little surprised by the idealism here.
It's not just idealism. It's also experience and foresight.
Mobile sites are notorious for trying to do more sniffing than they have
competence for. http://xkcd.com/869/ wouldn't be funny if the problem
wasn't so common. It's not good to give sites too much rope to shoot
their users in the foot with. I have concerns that even revealing the
distinction between "desktop" and "mobile" versions of Firefox is too
much sniffing surface that allows sites that assume that "mobile"
implies bad browser to send dumbed-down content to Firefox on Android or
Maemo.
Minefield tends to have the substring "pre" in its UA string, so some
sites think it's Palm Pre's default browser and sends downsized content.
Guessing how exactly sites trip themselves over so that they can be
evangelized appropriately would become even harder if there were a
zillion device identifier strings an arbitrary subset of which triggers
something special on some sites.
Suppose Firefox 4 for Android told sites that it's running on HTC Desire
when it is running on HTC Desire. The default browser on HTC Desire
doesn't support SVG but Firefox 4 for Android does. I think it would be
virtually certain that sites would show up serving SVG to Mobile Safari
but not to Firefox 4 for Android because they had some fancy device
capability database telling them that "iPhone supports SVG" but "Desire
doesn't support SVG".
There's really no point in setting up the possibility for sites to make
that mistake and then going on the evangelism treadmill to tell sites
not to make that mistake.
Note that Opera Mobile 11, which is the other mobile browser besides
Firefox 4 for Android/Maemo whose value proposition is being better than
the default browser on mobile devices, doesn't advertise the device make
and model in the UA string, so it evades sniffing that naively assumes
browser capabilities from the device name.
(Opera 11 is also interesting from the sniffing point of view in the
sense that both the Opera 11 with the desktop UI and Opera Mobile 11
with the mobile UI are available for tablets running Windows 7. The
choice of version is a matter of user choice, but both have the same
engine and both have zooming capabilities, so it doesn't make much sense
for sites to send different content to the two.)
> I presume it would cost next to nothing to
Stuff in the UA string is bytes sent out on every HTTP request.
> implement this in the same way that
> every other browser on the planet ever has,
Browsers typically don't tell the site what computer make and model you
are using.
> and that the HTTP spec
> clearly suggests you should.
Can you cite chapter and verse, please? I'm pretty sure the spec doesn't
suggest stuffing a device model identifier in the UA string.
> A claim that media queries make server-side adaptation unnecessary is
> extremely naive, if only for one logical reason: when I dispatch my
> resources, how am I going to know that the browser supports media
> queries at all if I don't even know what it is?
You can write your CSS in such a way that if media queries aren't
supported and the browser doesn't sniff as an old version of desktop IE,
the layout is left in a very simple state and media query support
enables enhancements. And these days, all mobile browsers worth using on
a daily basis support media queries anyway.
> Should I send multiple
> encodings of a single video to each browser in the hope it will be
> able to pick the most suitable one and ignore the others?
At least as far as the format axis of selection goes, you should offer
URLs to all the formats you have in the HTML markup and let the browser
pick the format. (So only single encoding of the video gets transfered.)
Even in this case, the evidence doesn't inspire confidence in sites
doing better with UA sniffing than leaving the choice to the browser's
HTML5 media selection algorithm. A site (http://vid.ly/) whose core
competence such sniffing is supposed be got it wrong in all the three
*desktop* browsers I have tested so far (two suboptimal choices and one
choice so wrong that the video didn't play). I tested Firefox 4, Chrome
12 dev and Opera 11.10 on 64-bit Linux (and I've reported the problem to
the site). Had the site offered the formats it had and left the choice
to the HTML5 media selection algorithm, the results would have been
better.
Unfortunately, there isn't yet automation for choosing among different
bandwidth version of a video. As an approximation, you could do what
YouTube does: offering 360p by default and letting users ask for a "HD"
version from the site UI.
> Should I
> even be sending progressively enhancing JavaScript if I don't know
> your browser supports it well? (Most mobile browsers still do not).
All mobile browsers worth using on a daily basis support JavaScript
anyway. And if that's not enough for you, it should be sufficient to
sniff for "Gecko" on any platform.
> In all honesty, contemporary server-side recognition (WURFL,
> DeviceAtlas etc) is probably far better than you're imagining - it's
> not just looking for plain keywords with a broad brush... and the
> quality of browser information keyed off these agent strings is
> generally very high, fast, and accurate.
Here's a competing client info repository breaking a site:
http://www.rohanradio.com/getting-aspnet-to-play-nice-with-opera-wget
(The same client info repo has a history of breaking sites with nightly
builds of Firefox, too, back when nightlies didn't say "Firefox" at all
in the UA string.)
> Suffice to say, this isn't a good start.
I think bsmedberg made the right call when he WONTFIXed the request to
add stuff to the UA string. (Thank you bsmedberg!)
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Boris Zbarsky
> Note that Opera Mobile 11, which is the other mobile browser besides
> Firefox 4 for Android/Maemo whose value proposition is being better than
> the default browser on mobile devices, doesn't advertise the device make
> and model in the UA string
Oh? So much for the claims that all other mobile browsers do that....
-Boris
Anders
option for you.
The solution is then simple:
1. Add a new HTTP header called -X-firefox-phone-UA that contains the
original UA
2. If you're concernced about traffic load and the users phonebill,
then just add the header when you get a Vary:User-Agent response from
the server
You would not break anything since this is a new header that no one
sniffs and only mobile sites that know what they are doing will use
this.
This is how Opera mini/mobile does it and it works well.
-Anders | @amaMobile
On Apr 4, 10:35 am, Henri Sivonen <hsivo...@iki.fi> wrote:
> On Fri, 2011-04-01 at 21:27 -0700, James Pearce wrote:
> > I'm more than a little surprised by the idealism here.
>
> It's not just idealism. It's also experience and foresight.
>
> Mobile sites are notorious for trying to do more sniffing than they have
> competence for.http://xkcd.com/869/wouldn't be funny if the problem
> hsivo...@iki.fihttp://hsivonen.iki.fi/
Anders
Opera do expose the device, they add device info in another header
field:
http://dev.opera.com/articles/view/opera-mini-request-headers/
This was mentioned in the original bugreport and is also mentioned as
a suggested solution to this problem that would not mess up existing
sites.
-Anders
Henri Sivonen
> 1. Add a new HTTP header called -X-firefox-phone-UA that contains the
> original UA
This is just a syntactic transformation that would enable pretty much the same anti-patterns as putting the same information in the UA string.
> 2. If you're concernced about traffic load and the users phonebill,
> then just add the header when you get a Vary:User-Agent response from
> the server
It's too late to add a request header based on a response header.
> You would not break anything since this is a new header that no one
> sniffs and only mobile sites that know what they are doing will use
> this.
For each mobile site that knows what it's doing, there are generally many more that don't.
> This is how Opera mini/mobile does it and it works well.
This isn't true. I just tested this on Symbian (Opera Mobile 11 and Opera Mini 6, the Symbian-native version--not the Java version).
First, neither Opera Mobile nor Opera Mini puts the device make or model in the User-Agent request header.
Opera Mobile does not send the UA string of the default browser in any request header. Further, Opera Mobile doesn't put the make or model of the device in *any* request header.
Opera Mini sends a request header called X-OperaMini-Phone that contains the make and model of the phone. Opera Mini also sends a header called X-OperaMini-Phone-UA that contains a value that looks like a UA string. However, it is *not* the UA string of the default browser! It is a different string that contains sniffing surface to identify the device make and model, the operating system & version and the MIPD & CLDC versions. That is, it's a string that has enough sniffing surface to cater for the use case of offering the right Java or Symbian-native installation package for the phone for software downloads, but it is not what it is labeled to be and that you, too, appear to have been tricked to believe it to be.
Henri Sivonen
>> Oh? So much for the claims that all other mobile browsers do that....
>
> Opera do expose the device, they add device info in another header
> field:
>
> http://dev.opera.com/articles/view/opera-mini-request-headers/
I said "Opera Mobile 11". The article you are pointing to is about Opera Mini.
> On Apr 4, 10:58 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
>> On 4/4/11 1:35 AM, Henri Sivonen wrote:
>>
>>> Note that Opera Mobile 11, which is the other mobile browser besides
>>> Firefox 4 for Android/Maemo whose value proposition is being better than
>>> the default browser on mobile devices, doesn't advertise the device make
>>> and model in the UA string
>>
>> Oh? So much for the claims that all other mobile browsers do that....
>>
Jim Smith
> On 4/2/11 12:27 AM, James Pearce wrote:
>
> If you send your images to that phone with a 200px by 300px screen and
> resize them server-side to that size and then the user saves the page as
> PDF and looks at it on their desktop or prints it you probably end up
> with an unhappy user.
Which is what media="print" is for, surely?
> > logic in the bug report.http://phon.me/?p=44
> > says that one consolation might be your likely lack of traction.
>
> He also has lots of concerns about low-end devices running UAs with
> limited JS capabilities. But if you see a mobile Firefox UA string,
> which we DO send, you know:
>
> 1) It's not a 2011-era low-end device.
> 2) It supports JavaScript.
And it's just one of over 2000 unique user-agents our site sees daily,
which represents some 1300 devices. Creating exceptions for devices
that don't do things the same way as others costs time and money that
we don't have, especially as the state of the art is progressing so
rapidly.
> So he too is arguing against the same strawman you have chosen.
Not a strawman - even when media queries are assumed to work, the
whole process of sending more data than the phone actually needs to
display a properly formatted page is abusive to the end user, who may
be on a very limited connection, and may be paying by the byte.
Further up the thread someone argues against adding the twenty bytes
or so required to indicate the device on precisely these grounds: it
works both ways.
I've slightly reordered your original post as I think this is the real
crux of the matter, so I've saved it for last:
> It would not cost us much in the way of work, no. It would cost our
> users something, though, and we would feel that we are selling them out.
This is the main issue for me. I can explain the positive use-cases
associated with device identification as much as I like (faster pages,
lower usage bills, better focussing of my team's R&D), but you won't
let me identify the device because it's become a privacy issue. I have
some sympathy with this viewpoint, but I think the balance between the
extra benefits the user gets from having right-sized pages is a valid
tradeoff against the few extra bits of info a blackhat would gain if
they were trying to track someone through their device user-agent.
Joshua Cranmer
> On Apr 2, 5:14 am, Boris Zbarsky<bzbar...@mit.edu> wrote:
>> On 4/2/11 12:27 AM, James Pearce wrote:
>>
>> If you send your images to that phone with a 200px by 300px screen and
>> resize them server-side to that size and then the user saves the page as
>> PDF and looks at it on their desktop or prints it you probably end up
>> with an unhappy user.
> Which is what media="print" is for, surely?
So, obviously, your media="print" stylesheet will surely override all of
the settings inferred by the User-Agent request headers, plus developers
worried about wasting dozens of bytes will surely include a link to the
media="print" stylesheet to every page to handle this rather uncommon
use case, especially when they are already unwilling to use media queries.
Henri Sivonen
On Apr 2, 5:14 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> > He also has lots of concerns about low-end devices running UAs with
> > limited JS capabilities. But if you see a mobile Firefox UA string,
> > which we DO send, you know:
> >
> > 1) It's not a 2011-era low-end device.
> > 2) It supports JavaScript.
>
> And it's just one of over 2000 unique user-agents our site sees daily,
> which represents some 1300 devices. Creating exceptions for devices
> that don't do things the same way as others costs time and money that
> we don't have, especially as the state of the art is progressing so
> rapidly.
If you aren't willing to put "Firefox" is general into the "supports
stuff that desktop browser support" bucket, why should we believe you'd
cater for "Firefox on device Foo", "Firefox on device Bar", "Firefox on
device Quux" more carefully as opposed to treating them the same as
"default browser on Foo", "default browser on Bar" and "default browser
on Quux"? For a product that is trying to be better than the default
browser, it doesn't make sense to enable sniffing that's likely to
result in getting lumped together with the default browser. (Consider,
for example, the SVG example from my earlier email to this thread.)
> Not a strawman - even when media queries are assumed to work, the
> whole process of sending more data than the phone actually needs to
> display a properly formatted page is abusive to the end user, who may
> be on a very limited connection, and may be paying by the byte.
Firefox hasn't really been designed for "pay by the byte" scenarios. For
example, Firefox Sync does uses connectivity in the background without
prompting the user about byte tallies.
Users who are paying by the byte are more likely to choose Opera Mini
than Firefox in order to deal with sites that aren't trying to
specifically optimize for "pay by the byte" users regardless of what
*your* site does.
> This is the main issue for me. I can explain the positive use-cases
> associated with device identification as much as I like (faster pages,
> lower usage bills, better focussing of my team's R&D), but you won't
> let me identify the device because it's become a privacy issue. I have
> some sympathy with this viewpoint, but I think the balance between the
> extra benefits the user gets from having right-sized pages is a valid
> tradeoff against the few extra bits of info a blackhat would gain if
> they were trying to track someone through their device user-agent.
If your concern is sizing stuff, why are you asking for the device name
and assuming you know how to correlate it with the size instead of
asking for the size?
That said, I don't really expect Firefox on any platform to start
sending screen or connection characteristics in an HTTP header. However,
if you really want to customize resource size to the screen size, you
could read the size in JavaScript and put it in a cookie. Then you could
optimize the responses to subsequent requests. As a bonus, this approach
would work across multiple pre-existing browsers without browser changes
and without having to maintain a device database.
Jim Smith
I don't know if you've been following this thread closely, but the
whole point about the lack of device info in the Fennec headers is
that there are no "settings inferred by the User-Agent request
headers". All the author of a page is allowed to know is that the
browser is a mobile variant of Firefox. The author doesn't know how
big the screen is, so can only hint as to how it should be represented
on different screens.
The save to PDF example can be solved by including it in a cascade of
media-queries, or by simply declaring a print media type on import, in
which case the browser is free to ignore it completely. The latter
seems like a more economical approach.
Jim Smith
> If you aren't willing to put "Firefox" is general into the "supports
> stuff that desktop browser support" bucket, why should we believe you'd
> cater for "Firefox on device Foo", "Firefox on device Bar", "Firefox on
> device Quux" more carefully as opposed to treating them the same as
> "default browser on Foo", "default browser on Bar" and "default browser
> on Quux"? For a product that is trying to be better than the default
> browser, it doesn't make sense to enable sniffing that's likely to
> result in getting lumped together with the default browser. (Consider,
> for example, the SVG example from my earlier email to this thread.)
By being on a certain device Firefox would end up with some, but not
all, of the same characteristics as the default browser, because they
both share the same root constraints - those of the device. But we
wouldn't want to bracket the default browser together with Firefox
(unless there was no discernible difference in required output, and
even then I'd be nervous). Screen size would be the same on both
browsers, but available screen might be different because they might
have different chrome.
As to your core point, which is whether I would assign Firefox Mobile
to a "desktop-like" bucket, there are two responses: one is that the
majority of devices we provide content for aren't as clever as
Firefox, and do need a non-desktop approach. While I can see the
attractiveness of using desktop techniques, I'd rather keep our code
consistent across all devices (I'm aware that this argument is really
down to how we choose to develop rather than an architectural
principle, but I'm disappointed that Mozilla don't want to allow us
the option). The second point is more architectural: just because a
device can do something, should we implement it? I'd say yes to this
only of it seemed appropriate in a mobile context: as the desktop
techniques encouraged by Mozilla result in a lot of unused data being
sent to the device, I'd say that it wasn't appropriate to mobile.
> Firefox hasn't really been designed for "pay by the byte" scenarios. For
> example, Firefox Sync does uses connectivity in the background without
> prompting the user about byte tallies.
That is actually a rather shocking statement. Surely when designing a
mobile-specific browser you should consider the circumstances under
which it will be used?
> Users who are paying by the byte are more likely to choose Opera Mini
> than Firefox in order to deal with sites that aren't trying to
> specifically optimize for "pay by the byte" users regardless of what
> *your* site does.
Agreed, and one thing I don't want to say is that my way is the *only*
way to approach mobile development. Media queries, adaptive design etc
may well be more appropriate for other sites. My problem isn't that
Mozilla are *encouraging* progressive web development, it's that
they're *blocking* the kind of approach we and much of the industry
take (such as Facebook -
http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
)
> If your concern is sizing stuff, why are you asking for the device name
> and assuming you know how to correlate it with the size instead of
> asking for the size?
>
> That said, I don't really expect Firefox on any platform to start
> sending screen or connection characteristics in an HTTP header. However,
> if you really want to customize resource size to the screen size, you
> could read the size in JavaScript and put it in a cookie. Then you could
> optimize the responses to subsequent requests. As a bonus, this approach
> would work across multiple pre-existing browsers without browser changes
> and without having to maintain a device database.
The reason for not requesting characteristics is that what's regarded
as useful and interesting keeps changing, and the amount of data that
would need to be sent would be regarded as excessive by browser
vendors. The mobile industry tried that approach with UAProf and user-
agent sniffing and device database grew despite the fact that almost
every device advertises its capabilities in a separate header.
In the firefox case we probably will end up using the cookie solution
if it gains enough traction to require special handling. That doesn't
seem like a very satisfactory solution to me, but it would be
workable.
Boris Zbarsky
>> If you send your images to that phone with a 200px by 300px screen and
>> resize them server-side to that size and then the user saves the page as
>> PDF and looks at it on their desktop or prints it you probably end up
>> with an unhappy user.
>
> Which is what media="print" is for, surely?
That works for background images, but for <img src> that doesn't work.
All you can do in your print stylesheet is rescale the image, and if it
was downsampled on the server you get ugly results.
> And it's just one of over 2000 unique user-agents our site sees daily,
> which represents some 1300 devices. Creating exceptions for devices
> that don't do things the same way as others costs time and money that
> we don't have, especially as the state of the art is progressing so
> rapidly.
As I said earlier in this thread, I appreciate your position and the
reasons for it. But I think that sending the hardware identifier would
not fit us into your existing infrastructure well (because you would
still need to tell us apart from the defaul browser), and would be
harmful to the web in the medium to long term and to our users throughout.
>> So he too is arguing against the same strawman you have chosen.
>
> Not a strawman - even when media queries are assumed to work, the
> whole process of sending more data than the phone actually needs to
> display a properly formatted page
The thing is, knowing the screen size (which I agree may be a legitimate
thing to want to know, by the way) doesn't tell you much about how much
data the phone needs: that also depends on the zoom level, on whether
the user wants to print, and so forth.
And as someone pointed out earlier, even for a given piece of hardware
the screen size is not constant....
>> It would not cost us much in the way of work, no. It would cost our
>> users something, though, and we would feel that we are selling them out.
>
> This is the main issue for me. I can explain the positive use-cases
> associated with device identification as much as I like (faster pages,
> lower usage bills, better focussing of my team's R&D), but you won't
> let me identify the device because it's become a privacy issue.
More precisely, privacy is one of the things we should consider and a
drawback (along with other drawbacks) that we need to balance against
the benefits of identifying the device. It's not a hard line,
obviously; we do identify various other information about the device.
-Boris
Anders
the most popular extensions to Firefox Mobile?
https://addons.mozilla.org/en-US/mobile/extensions/?sort=popular
-Anders
> take (such as Facebook -http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to...
Boris Zbarsky
> Is it not ironic that Phony, a User-Agent switcher plugin, is one of
> the most popular extensions to Firefox Mobile?
>
> https://addons.mozilla.org/en-US/mobile/extensions/?sort=popular
What would be interesting is to see data on what values users are
setting it to send.
-Boris
Henri Sivonen
> As to your core point, which is whether I would assign Firefox Mobile
> to a "desktop-like" bucket, there are two responses: one is that the
> majority of devices we provide content for aren't as clever as
> Firefox, and do need a non-desktop approach. While I can see the
> attractiveness of using desktop techniques, I'd rather keep our code
> consistent across all devices (I'm aware that this argument is really
> down to how we choose to develop rather than an architectural
> principle, but I'm disappointed that Mozilla don't want to allow us
> the option).
There are two main categories of mobile browsers: those that have
limited engines (including severely outdated snapshots of desktop
engines) and those that have a full up-to-date desktop engine but differ
from the desktop by being adapted to a different device form factor.
Firefox 4 for Android and Maemo, Opera Mobile and Mobile Safari are in
the latter category. As a user, if I'm using a browser in this latter
category but your site caters to desktop browsers and the mobile
browsers that have limited engines, I'd rather get the desktop version
of your site.
Since I know that's what I want as a user, I think Mozilla (or any
vendor of a mobile browser that has a full engine) should avoid getting
put onto the same code path as mobile browsers with limited engines on
sites that don't specifically cater to the category that Firefox for
Android/Maemo, Opera Mobile and Mobile Safari are in.
Again, if we look at what the most similar competing product, Opera
Mobile 11, is doing, it calls itself "Opera Mobi" instead of "Opera
Mobile" in its UA string--presumably because the string "Mobile" is
toxic and would result in getting lumped together with mobile browsers
that have limited engines.
(I'm generalizing above. There are notable mobile browsers that don't
fit into a "limited engine vs. full desktop engine" dichotomy, e.g.
Opera Mini and the Android default browser. The former has a full engine
on the server but can't use all its interactive features due to the thin
client architecture. The latter uses a real desktop engine but has a
substantial part of it disabled and lacks polished system-specific back
ends for some features.)
> > Firefox hasn't really been designed for "pay by the byte" scenarios. For
> > example, Firefox Sync does uses connectivity in the background without
> > prompting the user about byte tallies.
>
> That is actually a rather shocking statement. Surely when designing a
> mobile-specific browser you should consider the circumstances under
> which it will be used?
Firefox requires an ARMv7 CPU, so it's limited to devices that are
currently at the high end of the spectrum. I'd be rather surprised if
someone who buys a high-end device would be too cheap to get a data plan
that doesn't cost by the byte. After all, what's the point of a high-end
device if you aren't using it for Web browsing so much that you need a
data plan that doesn't cost by the byte? (Where I live, a device
suitable for running Firefox costs 450 euros or more with taxes and
suitable data plans start at less than 10 euros per month with taxes.)
> > Users who are paying by the byte are more likely to choose Opera Mini
> > than Firefox in order to deal with sites that aren't trying to
> > specifically optimize for "pay by the byte" users regardless of what
> > *your* site does.
>
> Agreed, and one thing I don't want to say is that my way is the *only*
> way to approach mobile development. Media queries, adaptive design etc
> may well be more appropriate for other sites. My problem isn't that
> Mozilla are *encouraging* progressive web development, it's that
> they're *blocking* the kind of approach we and much of the industry
> take (such as Facebook -
> http://www.facebook.com/notes/facebook-engineering/one-mobile-site-to-serve-thousands-of-phones/10150122073713920
> )
That article seems to be about also trying to support both mobile
browsers that have limited engines and mobile browsers that have
desktop-grade engines. Firefox provides quite enough sniffing surface to
let anyone who cares to put it in the "desktop-grade engine" bucket
together with Mobile Safari and Opera Mobile--where further tuning can
be done using media queries.
Benjmain Smedberg
> the most popular extensions to Firefox Mobile?
>
> https://addons.mozilla.org/en-US/mobile/extensions/?sort=popular
websites insist on serving me debilitated content designed for mobile
devices instead of real content. I have to choose to pretend to be
desktop Firefox in order to get useful content at my local news
websites. I suspect that our users might end up with a better experience
overall if the user agent said "Firefox" instead of "Fennec" and "Android"!
--BDS
Richard Gubby
Firstly, images, and more specifically, img tags.
With CSS background images, you can of course use media queries to load up different stylesheets based on screen width. It's still a bit clunky, as you get devices with all kinds of different widths and they don't all conform to one standard size. But you can kind of get around this.
img tags are another matter though, or at least from what I can tell they are. What I'm trying to do is build up a path to an image, so that when the page is rendered, the img tag points to a path of an image that not only fits in terms of screen dimensions, but is also the right file size.
I could use a CSS media query to set the max-width, or just have max-width:100%. But it's still going to load up my original image, which may have to be 1000 px x 1000 px to accomodate - it's going to be big. If everyone on a mobile phone had a broadband speed connection it wouldn't be a problem, but they don't, so it is.
I could also display a whole bunch of images on the page, and use media queries to hide them if they are less than or greater than a certain width. This is probably a worse scenario than the previous idea.
Another solution is to add some JavaScript that runs at the top of the page and changes all of the img src paths based on the screen width. This potentially could work, but it's a massively hacky way of doing what you want.
If someone has a solution to this, I'm all ears.
The 2nd issue I have is not knowing what the actual device is.
There are plenty of instances where someone has a mobile app, and wants to promote it on the mobile version of the website. There might be different builds based on the version of Android - but the useragent passed through only contains "Android", and that's it. I don't know for sure if you have different versions of apps on different versions of Android, so that may be a moot point, but I may be right.
The last thing is how are you supposed to know whether the browser hitting your site is a mobile? Sniffing the Fennec useragent and using that? Surely that is as bad as providing the original device UA..
I'm sure the response will be to use media queries to work out screen width, etc, but I want to actually deliver a different experience on a mobile handset. I have a website that when someone is using it on a mobile device, I want it to do very different things to when they are on a desktop.
I might have a web app that allows you to keep score at a baseball game - who brings a laptop to a baseball game? And when you get home, you can compare how you scored against the actual scoring... I want the same URL for both, I don't want an m. sub domain and the only way I can do it is to sniff the Firefox UA.
If possible, I'd like the device info actually supplied in http headers, so at the very least, the vendor and model, and anything else that might help - so screen size for sure. It's not giving away anything that isn't being done on the desktop Firefox - after all, Google Analytics knows all about the screen sizes of the browser. The difference of course with GA on a web browser, is that it doesn't need these at page execution, whereas a mobile web page probably does.
Thanks.
Henri Sivonen
> Discussion followup to bug 625238
> <https://bugzilla.mozilla.org/show_bug.cgi?id=625238>.
This thread and the above bug resulted in a decision not to expose the
device name in the UA string. Yet,
https://bugzilla.mozilla.org/show_bug.cgi?id=671634 landed in
contradiction with the earlier decision. (Note that the patch does
more than what the bug title says.)
I think it would be appropriate to revert the part of that added the
device name to the UA string.
Dao
the newsgroup discussion, in a misleadingly summarized bug, filed in the
wrong component and without proper peer review. On top of all this, the
patch landed on the day of the aurora merge.
The patch has been backed out.
Mark Finkle
in those threads. I see a lot of discussion about why web developers
want it and why other people can't see the need for it, or UA sniffing
in general.
Henri Sivonen
discussion moved to this newsgroup/mailing list thread. The discussion
didn't lead to the bug getting reopened, which I understood as the
arguments against exposing device info in the UA string being stronger
and the WONTFIX decision being upheld by the conclusion of the
discussion.
(FWIW, personally, I'm now reluctantly ok with distinguishing between
"Mobile", "Tablet" and "Desktop" but not with identifying the device
model.)
Doug Turner
> https://bugzilla.mozilla.org/show_bug.cgi?id=625238 is WONTFIX and the
> discussion moved to this newsgroup/mailing list thread. The discussion
> didn't lead to the bug getting reopened, which I understood as the
> arguments against exposing device info in the UA string being stronger
> and the WONTFIX decision being upheld by the conclusion of the
> discussion.
>
I appreciate your purism here. Many many times we are getting the wrong content when we hit a web site. If you do head to head comparisons between us and the default browser, their UA String is getting them the content that is best suited for the Android device's screen. And I am not talking about WebKit specific things, I am talking about the mobile friendly version that isn't the wap/mobile version.
> (FWIW, personally, I'm now reluctantly ok with distinguishing between
> "Mobile", "Tablet" and "Desktop" but not with identifying the device
> model.)
Doug
Doug Turner
Doug
Kevin Brosnan
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Once we start doing this going back is unlikely given that we are
reluctant to remove legacy bits of the Firefox desktop UA. So far the
majority of the feedback I've seen is from individuals and companies
that create and maintain lists and tools based on device ID.
kbrosnan
Henri Sivonen
>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=625238 is WONTFIX and the
>> discussion moved to this newsgroup/mailing list thread. The discussion
>> didn't lead to the bug getting reopened, which I understood as the
>> arguments against exposing device info in the UA string being stronger
>> and the WONTFIX decision being upheld by the conclusion of the
>> discussion.
>>
>
> Henri,
>
> I appreciate your purism here.
name in the UA string or do you mean the text you quoted about
decision process is purism?
> Many many times we are getting the wrong content when we hit a web site. If you do head to head comparisons between us and the default browser, their UA String is getting them the content that is best suited for the Android device's screen. And I am not talking about WebKit specific things, I am talking about the mobile friendly version that isn't the wap/mobile version.
databases on Android. If we go along with the device database
anti-pattern, we will be contributing to making Firefox on the next
mobile platform (I hope there will be others than Android) a victim of
device mapping databases.
Note that if we get a "wap/mobile" version, it just shows how clueless
these device databases (or their clients) are, since any reasonable
database would group the "Fennec" token alone in the post-wap
iPhone/Android-era class. If we haven't gotten as far as getting the
databases to map "Fennec" to "not the old wap junk", have the changes
in the patch in question been actually tested against clueless
databases or sites using databases cluelessly?
If putting the name of an Android device in the UA string tests well
against clueless sites, should we be spoofing the name of the most
popular Android device on all similarly-sized Android devices in order
to avoid putting the users of equally capable but not equally known
devices at a disadvantage?
Henri Sivonen
> If putting the name of an Android device in the UA string tests well
> against clueless sites, should we be spoofing the name of the most
> popular Android device on all similarly-sized Android devices in order
> to avoid putting the users of equally capable but not equally known
> devices at a disadvantage?
does differentiate between phones ("Opera Mobi") and tablets ("Opera
Tablet"), though.
Matt Brubeck
small-screen devices (e.g. phones) from large-screen devices (tablets),
without leaking additional information about the device. However, we
should be willing to change this in the future when we've taken the time
to gauge its effects. Adding "Mobile" on small-screen devices seems
like a reasonable first step, although it might backfire.
(Opera Mobile uses "Mobi" instead of "Mobile" in its UA to avoid being
treated as a low-capability mobile browser. "Tablet" on tablets might be
better if we find the same problem affects us.)
Since we have near 0% market share on mobile, our influence is very
limited. If some of our attempts to improve the mobile web are hopeless
now because we lack users, then we might need compromises to get better
user experience and more users in the short term, and hope this buys us
more influence in the future. But adding the device name to the UA
string now seems like declaring premature defeat, and possibly for no
benefit.
We have had made slow but steady progress with evangelism efforts to get
sites to fix UA sniffing that breaks for Fennec. Tablet hardware has
just added one more way for this to break. Changing our UA can give
authors an easy way to fix that.
No matter what change we make, it will take some time for us to
evangelize it and for publishers to update and deploy code to handle it.
If we think that adding a binary small/large token solves the major
problem here, then we should try that approach first, and remember that
it will take some time to see if it works.
I'm not convinced that adding the device name will help us with any
existing sites anyway. Based on the code of WURFL (the best-known
device database), it will have zero effect on sites using such databases
today since they sniff specifically for the stock browser's UA. If the
databases are updated then it will start having an affect on sites using
newer versions -- but that update would be based on the choices we make
now, so we are not yet forced into any particular choice. If this is
the case, then we should make the choice that will make it easier for
new devices and browsers to participate in the web, not harder.
Adding the device name can also backfire, if it leads some servers to
think the browser's features match the stock browser on a given device.
Does anyone knows of any existing device libraries or sites where the
user experience is improved by adding the device name to our UA? Any
sites where it makes the experience worse? On most sites that exist
today, there seems to be no change.
Henri Sivonen
> Adding "Mobile" on small-screen devices seems like a
> reasonable first step, although it might backfire.
>
> (Opera Mobile uses "Mobi" instead of "Mobile" in its UA to avoid being
> treated as a low-capability mobile browser. "Tablet" on tablets might be
> better if we find the same problem affects us.)
Tablet;" or go for something really short and use " M;" and " T;". ("
N;", " U;" and " I;" are historically taken, but AFAIK, " M;" and "
T;" aren't.) I think we shouldn't use "Mobile", because there has to
be a reason why Opera doesn't use it.
> Since we have near 0% market share on mobile, our influence is very limited.
bootstrapping market share if it brings big wins. Everyone except
Mozilla/Netscape has done it at some point. Opera gets away without
exposing the device name in the UA string in Opera Mobile. If they
have a more established successful sniffing history without device
names, I think we should be open to researching if putting "like Opera
Mobile" or "like Opera Tablet" in the UA string would be a big win.
(Trying to get sniffed as Opera instead of trying to get sniffed as
WebKit would probably be better in terms of the risk of getting
foreign vendor prefixes fed to us as a side effect.)
> But adding the device name to the UA string now seems like
> declaring premature defeat, and possibly for no benefit.
wap-style stuff, I think the conclusion to draw is that we should
design solutions that work even if the site author in incompetent and
uses an incompetently maintained and habitually out-of-date device
database.
> Adding the device name can also backfire, if it leads some servers to think
> the browser's features match the stock browser on a given device.
on Android 2.x doesn't support SVG.
More generally, I think we should design a solution that ensures that
if the same version of Firefox runs on two devices from different
vendors and the devices are equivalent in capability, Firefox on both
devices sniffs the same way (and gets the same content experience)
even if the site author is incompetent and uses an incomptently
maintained and out-of-date device database. Having different UA
strings on two equivant devices makes the results a lottery for the
users and a lottery for debugging.
(Hypothetical scenario that we should avoid: Mozilla developers and QA
use a lot of Samsung and Asus tablets. Everything looks fine. Product
gets shipped. Later we learn that the Web experience is terrible for
users of HTC and Lenovo tablets because they sniff differently.)
Matt Brubeck
> On Tue, Nov 8, 2011 at 7:45 PM, Matt Brubeck<mbru...@mozilla.com> wrote:
>> Adding "Mobile" on small-screen devices seems like a
>> reasonable first step, although it might backfire.
>>
>> (Opera Mobile uses "Mobi" instead of "Mobile" in its UA to avoid being
>> treated as a low-capability mobile browser. "Tablet" on tablets might be
>> better if we find the same problem affects us.)
>
> I think we should either reuse Opera's pattern and use " Mobi;" and "
> Tablet;" or go for something really short and use " M;" and " T;". ("
> N;", " U;" and " I;" are historically taken, but AFAIK, " M;" and "
> T;" aren't.) I think we shouldn't use "Mobile", because there has to
> be a reason why Opera doesn't use it.
apply. Android and Safari both use "Mobile" in their UA with no
apparent bad effects. (Of course authors are more likely to find and
fix problems in those two browsers, so they might be able to get away
with more than less-popular can.)
As a side note, some versions of Opera do send the device name in the
HTTP request headers, though as far as I can tell the current version of
Opera Mobile for Android does not.
Justin Dolske
> I'm not convinced that adding the device name will help us with any
> existing sites anyway. Based on the code of WURFL (the best-known device
> database), it will have zero effect on sites using such databases today
> since they sniff specifically for the stock browser's UA.
other supporting/contrary data wrt to making sites work via exposing a
more detailed UA?
It's been a contentious issue in the past (even on Desktop), and so I
think my default stance would be that we shouldn't muck with the UA
unless there's data to show there's a clear benefit. If nothing else,
it's a big distraction from all the other work that needs to get done.
Justin
Gervase Markham
> We have had made slow but steady progress with evangelism efforts to get
> sites to fix UA sniffing that breaks for Fennec. Tablet hardware has
> just added one more way for this to break. Changing our UA can give
> authors an easy way to fix that.
>
> No matter what change we make, it will take some time for us to
> evangelize it and for publishers to update and deploy code to handle it.
> If we think that adding a binary small/large token solves the major
> problem here, then we should try that approach first, and remember that
> it will take some time to see if it works.
project-wide web evangelism efforts to get site authors to fix their
sites for Gecko. We did this even though it took a while to see
improvements, because we believed that the anti-patterns we were
fighting were bad for the web, and bad for innovation and competition
and new entrants (both in hardware and browsers).
We can do the same things on mobile, working with device database
vendors and individual sites to try and make things better. We just need
someone to issue a rallying cry and define what needs to be done.
Gerv
Henri Sivonen
> This is important. In the past, we have spun up significant,
> project-wide web evangelism efforts to get site authors to fix their
> sites for Gecko. We did this even though it took a while to see
> improvements, because we believed that the anti-patterns we were
> fighting were bad for the web, and bad for innovation and competition
> and new entrants (both in hardware and browsers).
principled approach. Going the same route we went a decade ago or
adding all the cruft that the stock browser has to the UA string that
gets sent on every HTTP request are not the only options, though.
Having a non-crufty and clearly Gecko-esque UA string by default and
sending specially crafted UA strings to notable sites that send us
unoptimal content is one possibility.
After Netscape's first engine*, Mozilla is the only major vendor that
has fought its way through to establishing a new major browser without
resorting to site-specific UA strings on the way. But was it important
to do it that way? The others (Opera, Chrome, IE, Safari) have at one
point or another used site-specific UA strings. While having one UA
string that is short and doesn't have much fingerprinting surface
would be my first preference, I think having site-specific UA string
hacks is a lesser evil than putting all the stuff that the Android
stock browser has in its UA string in our UA string. The reason why I
think site-specific UA strings are a lesser evil is that site-specific
strings don't make the browser more fingerprintable and site-specific
strings don't bloat HTTP requests sent to most sites.
Site-specific strings, of course, actually require per-site
experimentation of what the most successful UA string for each
misbehaving top site is. (But that experimentation is still less work
than evangelizing sites.)
In general, I think we should be scientific / empirical about putting
cruft in the UA string. We shouldn't cargo-cult copy the Android stock
browser. Looking at the latest batch of patches in bug 671634 that
seek to e.g. add the Android version number to the UA string, I have
to wonder if the changes actually have a solid experimental basis
(i.e. the changes having been tested and found successful with
important sites that sniff us badly at present). Is there empirical
evidence that a UA string that contains the Android version number
makes Firefox get more suitable content given existing sniffers, for
example? (I doubt it, but I haven't researched it.)
* Netscape's first engine didn't have the UA string problem yet.
Sending richer content to Netscape than everyone else is what started
the UA string problem.
Mark Finkle
Matt Brubeck
> On 11/8/11 9:45 AM, Matt Brubeck wrote:
>
>> I'm not convinced that adding the device name will help us with any
>> existing sites anyway. Based on the code of WURFL (the best-known device
>> database), it will have zero effect on sites using such databases today
>> since they sniff specifically for the stock browser's UA.
>
> This is the most interesting point I've seen made here. Is there any
> other supporting/contrary data wrt to making sites work via exposing a
> more detailed UA?
finished so far. I tested the following eight URLs that redirect to
different desktop or mobile versions depending on the browser:
finance.google.com
Yahoo.com
IMDB.com
Bing.com
Live.com
en.wikipedia.org
Youtube.com
mail.google.com
And I tested the following UA headers:
1. Fennec 8 default
2. Fennec 8 + "Android/2.2"
3. Fennec 8 + "Android/2.2; Nexus One Build/ERE27"
4. Stock Browser (Nexus One)
Within this small sample, adding the Android OS version improved the
experience on one site (live.com). Adding the device model did not
improve the experience on any additional sites, but it did cause new
breakage on two sites (yahoo.com and bing.com). Of the eight sites,
three serve different versions to Gecko than to WebKit UAs regardless of
these changes.
Detailed results:
finance.google.com
1. broken layout
2. broken layout
3. broken layout
4. mobile
Yahoo.com
1. mobile
2. mobile
3. mobile WebKit version (broken in Gecko)
4. mobile WebKit version (broken in Gecko)
IMDB.com
1. desktop
2. desktop
3. desktop
4. mobile
Bing.com
1. mobile lo-fi
2. mobile lo-fi
3. broken layout
4. mobile
Live.com
1. mobile lo-fi
2. mobile
3. mobile
4. mobile
en.wikipedia.org
1. mobile
2. mobile
3. mobile
4. mobile
Youtube.com
1. mobile
2. mobile
3. mobile
4. mobile
mail.google.com
1. mobile lo-fi
2. mobile lo-fi
3. mobile lo-fi
4. mobile
Gervase Markham
> Having one UA string and doing a lot of evangelism is the most
> principled approach. Going the same route we went a decade ago or
> adding all the cruft that the stock browser has to the UA string that
> gets sent on every HTTP request are not the only options, though.
> Having a non-crufty and clearly Gecko-esque UA string by default and
> sending specially crafted UA strings to notable sites that send us
> unoptimal content is one possibility.
with a list auto-update system so they can stop doing it when sites fix
themselves. I think we would need this too if we went down this route.
Gerv
Neil
having to spoof Firefox except on sites that need it.
--
Warning: May contain traces of nuts.
Henri Sivonen
alterations. To my knowledge, when Safari and Chrome have sent a
different UA string to a particular site, they have hard-coded it
without an update mechanism other than updating the browser itself.
Opera has the most elaborate system. The browser downloads (and keeps
updating) a file that not only can set different UA strings on a
per-site basis but can inject arbitrary JavaScript into sites so that
Opera can fix compatibility bugs that go beyond UA sniffing.
IE8 introduced an updating list of sites that get the Compatibility
Mode. In that mode, IE8 sends a UA string that sniffs as IE7 and the
browser emulates IE7 in other ways. I remember reading an article on
some Microsoft site that revealed that in IE10, the Microsoft-supplied
list of sites that need special treatment can tell IE10 to send a UA
string that sniffs as iPad (so that can trick sites into serving H.264
in <video> instead of ActiveX/Flash). I can't locate that article
right now, though. Already in IE9, they went into a slightly more
Opera-like direction and made it possible for the list to cause IE9 to
cherry-pick certain legacy behaviors instead of going all the way to
IE7 emulation.
At one time, Hotmail was blocking Chrome, so Chrome added a hard-coded
rule for showing a different UA string to Hotmail. Likewise, they've
had a hack where they made the Linux version of Chrome claim to be the
Windows version when using Yahoo! Mail. The update mechanism was
simply pushing a new Chrome release later.
IIRC, when Safari for Windows launched, Apple made it pretend to be
Safari for Mac when accessing Flickr. Safari (at least on Mac) has an
optional Debug menu that allows all site-specific hacks to be toggled
on or off, so site developers can test their stuff with the
site-specific hacks turned off. There's no autoupdate mechanism apart
from updates to Safari as a whole. Safari has had site-specific hacks
that don't vary the UA string. One hack is known to be Web app
specific instead of site-specific: An old version of Mediawiki serves
a bad style sheet to Safari. When Safari detects that it has received
that style sheet, it behaves in a slightly special way. (This hack
isn't site-specific, because even though Mediawiki was fixed on
Wikipedia, old versions of Mediawiki continue to be deployed all over
the Web.) My understanding is that the hacks that are inside WebKit
itself (such as the Mediawiki hack) apply in other WebKit-using
browsers, too, including Chrome.
Conclusions:
* All top browsers except Firefox take site-specific counter-measures
when sites serve them bad stuff. (I have a vague recollection that we
have had Web server name/version-based countermeasures in Necko
against server bugs--not site-specific, though.)
* All the other top browsers have gone beyond mere UA string
variability in their site-specific hacks, so it could be viewed as a
slippery slope.
* An autoupdating list of site-specific hacks makes response fast.
However, it is possible to simply rely on browser updates
instead--especially with a rapid release cycle.
* Even the difference between Mac/Windows/Linux in the UA string is a
problem that browsers have had to add hacks for. In this light, it
seems to me that adding device-specific UA string variation is just
asking for trouble by creating yet another attractive nuisance* in the
UA string.
* http://en.wikipedia.org/wiki/Attractive_nuisance_doctrine
Henri Sivonen
> I've started doing some small-scale data gathering. Here's what I've
> finished so far.
the board, but sending a different browser's UA string in its entirety
on a site-specific basis could yield wins.
Gervase Markham
dev.planning about this topic)
On 11/11/11 08:28, Henri Sivonen wrote:
> Opera and IE have an autoupdate system for their site-specific
> alterations. To my knowledge, when Safari and Chrome have sent a
> different UA string to a particular site, they have hard-coded it
> without an update mechanism other than updating the browser itself.
An awesomely comprehensive overview of the landscape!
From this, it seems to me that bad UA sniffing causes problems, and the
more stuff in the UA, the more scope for bad sniffing. If we try and fix
bad sniffing by adding more sniffing 'surface', we will just make the
problem worse further down the road.
The way other browsers have tried to get out of this vicious circle is
via site-specific hacks - so keeping the UA cruft-free, but doing things
on particular sites to make them work until the sites fix themselves. I
think we should have an evangelism strategy, backed up by this possibility.
Gerv
dtre...@gmail.com
> Discussion followup to bug 625238
> <https://bugzilla.mozilla.org/show_bug.cgi?id=625238>.
After reading through this discussion thread as well as the comments on the bug report page, I think that there is one reason to expose the running Android version in the userAgent string that has not been discussed yet. Consider trying to make a website that closely replicates the look-and-feel of a native Android app. Correct me if I am wrong, but in order to do this reasonably well you need to know the running Android version in order to use an appropriate visual theme, and this cannot be accomplished with media queries or other standard APIs.
Suppose further that you were going to develop the website using Google Web Toolkit (to take advantage of one of the mobile GWT app development frameworks). In GWT, the deferred binding mechanism is based on browser sniffing (usually using information extracted from the navigator.userAgent string, but other snippets of JavaScript can be used as well). You could define a custom compilation property for the Android version and then bind an appropriate CssResource, one for each theme, according to the detected Android version.
I realize that selecting a theme based on the Android version alone is not perfect (after all, Android currently provides two system themes, Holo Light and Holo Dark), but at least it would be a start, and it should be possible to guess correctly for a majority of the users. Better yet, if the theme name were somehow included after the Android version, such as "Android 4.3 Holo Dark", then the website would not need to ask the user for the theme that he or she is using. In general, I feel that having to ask users for these pieces of information detracts greatly from the user experience.
I for one would love to be able to do this, adapt the look-and-feel of a webpage to the native theme. However, if the user is using Firefox for Android, then I would have to guess a theme, and I would probably just pick the latest one. This would be problematic if Google decides to make a major redesign in the future.
Would Mozilla consider adding information to the userAgent string to enable this automatic theme selection technique?
Lawrence Mandel
Lawrence
Henri Sivonen
> Correct me if I am wrong, but in order to do this reasonably well you need to know the running Android version in order to use an appropriate visual theme, and this cannot be accomplished with media queries or other standard APIs.
Android version, either. How would you handle TouchWiz or Sense?
Does -moz-appearance do anything on Android?
--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/