Firefox Mobile UA and You
Mark Finkle
Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110920
Firefox/9.0a1 Fennec/9.0a1
Note: It mentions "Android" and "Fennec"
Web developers have been filing bugs for a while now to have Mozilla add
information about the device to the UA. We have been pushing back,
saying UA sniffing is not good for the web and that there are client
side ways of detecting physical constraints.
Now that we have build of Firefox that work really well on Android
tablets, we see a new request: Can we get different content for tablet
vs. phone?
We still only support the above UA for tablets and phones, so web
properties can't UA sniff for this difference either. We end up with
many bugs filed for individual websites looking badly in Firefox, for
both phone and tablet.
Google actually has a guideline for UAs on Android:
http://android-developers.blogspot.com/2010/12/android-browser-user-agent-issues.html
<quote>
Currently, Android devices provide the following (in addition to
standard info) in the User-Agent: "Android", a version number, a device
name, a specific build, Webkit version info, and "Mobile"
The "Mobile" string in the User Agent indicates that this device would
prefer a version of the website optimized for Mobile (small form factor
devices), if available.
We recommend that manufactures of large-form-factor devices (where the
user may prefer the standard web site over a mobile optimized version)
remove "Mobile" from the User Agent (and keep the rest of the User Agent
as currently implemented). Web sites can then key off "Mobile" in the
User Agent to decide on which UI version to present to the device.
</quote>
If we wanted to follow this same concept, we could:
1. Add "Mobile" for small form factors
2. Add <device> all the time
Any thoughts on making a change like this? This would probably be for
Mobile only. I don't think desktop UA would need to be changed.
Dao
> 1. Add "Mobile" for small form factors
> 2. Add <device> all the time
mobile-optimized page for phones but not tablets?
Ehsan Akhgari
Mark Finkle
> On 21.09.2011 16:52, Mark Finkle wrote:
>> 1. Add "Mobile" for small form factors
>
> Would we remove the Fennec token in exchange?
>> 2. Add <device> all the time
>
> What for? Doesn't "Mobile" address the primary concern of providing a
> mobile-optimized page for phones but not tablets?
like "Nexus One", and provides details about screen sizes, keyboard
types, etc
Mark Finkle
>> 2. Add<device> all the time
>>>
>>
>> What for? Doesn't "Mobile" address the primary concern of providing a
>> mobile-optimized page for phones but not tablets?
>
>
> Also note that adding<device> has fingerprinting consequences.
One" is pretty vague. On desktop we do things like:
"Linux i686 on x86_64" or "Windows NT 6.1; WOW64"
Rob Manson
UA sniffing is not "bad for the web"...it's just one of a suite of tools
that can be used for eloquently delivering a seamless multi-device
experience for our users.
roBman
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Boris Zbarsky
> UA sniffing is not "bad for the web"...it's just one of a suite of tools
> that can be used for eloquently delivering a seamless multi-device
> experience for our users.
also in lots of really broken ways.
Fundamentally, UA sniffing is what people fall back on when they don't
actually have a good tool for the job. And the UA sniffing tool is
_really_ hard to use right. I have yet to encounter a site that manages
it "correctly", actually. I'm not sure such a thing is even possible.
The closest analogy I can think of with actual tools is using an
operating chainsaw any time you don't have the tool you _really_ need
for the job. Need a nail put in and don't have a hammer? Turn on the
chainsaw and use the case to bang on the nail! Can it save you in a
pinch? Yes. Will there be some lost fingers over time? Almost
certainly. Is having to use it a good state of things? No.
-Boris
Matt Brubeck
> UA sniffing is not "bad for the web"...it's just one of a suite of tools
> that can be used for eloquently delivering a seamless multi-device
> experience for our users.
*does* hurt interoperability on the web in many ways, and we do need to
balance that cost against the benefits.
This is not just theoretical; we have run into it many, many times.
Sniffing has especially bad effects on less-used browsers and devices.
For example, many sites and libraries assume that Firefox on Android
uses WebKit or shares specific bugs with the stock Android browser,
because it has "Android" in the UA header.
These problems especially hurt users of newer browsers, since there's no
way for the authors of the UA sniffing code to anticipate those
browsers' UA strings. This makes it harder for new competition to enter
the browser market. This is obviously bad for innovation.
I agree we need to provide more information in our UA, but I hope this
explains why we are being careful about it.
In particular, I worry that putting device names in the UA may help for
sites that use that info to look up screen sizes, but will also create
bugs when they use it to look up other browser capabilities (e.g. video
codecs, support for web standards, etc.). Since Firefox has the same
web standards support on all devices, most sites will get better results
from treating Firefox the same everywhere, and using techniques like
feature detection, accept headers, and media queries to determine
browser and device characteristics.
Dao
mobile UA string: Android; Linux armv7l
Dao
> On 09/21/2011 11:31 AM, Dao wrote:
>> On 21.09.2011 16:52, Mark Finkle wrote:
>>> 1. Add "Mobile" for small form factors
>>
>> Would we remove the Fennec token in exchange?
>
> Maybe. But remember, "Mobile" would only appear for phones, not tablets.
tablet as on my desktop PC and laptop.
>>> 2. Add <device> all the time
>>
>> What for? Doesn't "Mobile" address the primary concern of providing a
>> mobile-optimized page for phones but not tablets?
>
> Many websites use a UA sniffing system that keys off of the device name,
> like "Nexus One", and provides details about screen sizes, keyboard
> types, etc
I think we should promote proper APIs where we see the need and
discourage device -> feature set mappings.
Rob Manson
to hurt people, hit their own fingers, etc.). But that doesn't mean
they shouldn't exist. That just means people tend to abuse tools for
their own needs.
You "can" rely on client-side only detection of capabilities and media
queries, etc. But not all mobile devices support this correctly...and
this is also one of the reasons that the "startup" web experience is
often used as an example of how native apps are better than web apps.
If we can accurately identify a device/browser combination and we do
know the capabilities etc. then we "may" choose to pre-bundle/package a
lot of resources and deliver them in the initial network request. In
apps where we have a good understanding of the target users and their
devices and they have limited network connections then this is a valid
and useful option.
We always aim to allow people to use switchers and have other options so
they can access resources in different ways...but we also usually aim to
optimise the first "startup" experience.
Saying we "should not do this" is cutting off your nose to spite your
face.
Saying we "should do this in a well thought out way" is a valid comment
and I'm confident that we do. But the browser world is a very
imperfect, heterogeneous environment and we need all the options we can
to make the web app experience as good as the native app experience.
roBman
Mike Shaver
> this is also one of the reasons that the "startup" web experience is
> often used as an example of how native apps are better than web apps.
How do native Android apps query and modify their behaviour based on
the device they're on? There must be a hundred different screen and
keyboard and hardware-button-layout combinations from just Samsung
alone. Do they keep a device database somewhere, or do they look at
information on screen dimensions, type of keyboard, etc.?
Mike
Rob Manson
careful about something like this that has broad implications is
definitely sensible.
I'm just voicing the alternate opinion that UA sniffing is not
inherently evil.
Often abused and poorly thought out...yes!
Evil...no!
roBman
Boris Zbarsky
> People use hammers in really broken ways too (e.g. to hold doors open,
> to hurt people, hit their own fingers, etc.). But that doesn't mean
> they shouldn't exist.
borrow a hammer to hold this door open?" you should consider giving them
a doorstop instead of what they actually asked for.
Again, I'm all for exposing device capability APIs as needed. I think
the UA string listing the device model is the wrong way to expose them...
-Boris
Mike Shaver
> Often abused and poorly thought out...yes!
web is hurt by practice, not theory.
> Evil...no!
Indeed, I don't think we should ascribe moral attributes to UA
sniffing. I don't think anyone has, though!
Mike
Rob Manson
> Sure, I remembered this... I actually want the same web experience on
> my tablet as on my desktop PC and laptop.
Your desktop PC almost certainly doesn't support the orientation API and
a whole range of other sensors that are permeating the mobile device
space (mobile as in smartphone and tablet).
I want the same data and web service functionality across all my
devices...but I certainly don't want the same UX.
NOTE: This is not a comment about the UA point that kicked off this
thread...just a response to your comment above.
roBman
Boris Zbarsky
> Your desktop PC almost certainly doesn't support the orientation API
in fact does support the orientation API, last I checked.
> and a whole range of other sensors that are permeating the mobile device
> space (mobile as in smartphone and tablet).
not (yet) have a compass or built-in GPS, but I wouldn't be surprised to
see those appear in the near future.
> I want the same data and web service functionality across all my
> devices...but I certainly don't want the same UX.
has to do with weight, not with lack of the orientation API...
-Boris
Rob Manson
this is not just Android apps...but native apps full stop. The key
point is that they don't require extra network requests each time they
startup. They usually have all the resources based on the capability
profile installed locally.
Customising layout etc. based on screen size for example is often done
by introspection (if at all) but kind of similar to a media query.
However, once that screen size is known it doesn't require a network
connection to then get that presentation definition (e.g. css).
Sure you can inline all the different options in css but then that's a
waste of bandwidth. Effectively this is what native apps do...but then
they aren't delivered over the network each time they're loaded.
Using localstorage/manifests to make them behave more like installed
apps is a better solution...but most web devs aren't doing this yet.
roBman
Dao
> On Wed, 2011-09-21 at 19:18 +0200, Dao wrote:
>> Sure, I remembered this... I actually want the same web experience on
>> my tablet as on my desktop PC and laptop.
>
> Then you're doing a discredit to your tablet.
>
> Your desktop PC almost certainly doesn't support the orientation API and
> a whole range of other sensors that are permeating the mobile device
> space (mobile as in smartphone and tablet).
>
> I want the same data and web service functionality across all my
> devices...but I certainly don't want the same UX.
apparently optimized for phone browsers written in Java on my tablet.
Rob Manson
I made the exact same point you did below in a public presentation
recently and I was amazed at the number of people in the audience that
claimed they still use actual "desktop" PCs. So I'd say that a "laptop"
is clearly not a "desktop".
I definitely agree that the sensors from mobile devices are now leaking
back into the PC devices. But your point about the UX is the important
bit. People use these different classes of devices in different
ways...and the ability to embrace that difference while seamlessly
working across them all is one real strategic advantage I see that the
web has over native apps.
BTW: I agree with your comment about the hammer/door stop too and would
also agree that some people shouldn't be allowed hammers full stop 8)
roBman
Mike Shaver
> Using localstorage/manifests to make them behave more like installed
> apps is a better solution...but most web devs aren't doing this yet.
match-device-characteristics problem which doesn't rely on device
identification, which is exactly the path that people are proposing
here: use media queries, etc.
That many web developers *aren't* using the tools they have now to
reduce network traffic seems to bear not at all on the question of
whether "device type qua device type" should be exposed in the UA
string or otherwise.
Mike
David Illsley
David
On 21 Sep 2011, at 18:28, Rob Manson <roB...@mob-labs.com> wrote:
> I agree...all of your comments here are perfectly valid...and being
> careful about something like this that has broad implications is
> definitely sensible.
>
> I'm just voicing the alternate opinion that UA sniffing is not
> inherently evil.
>
>
>
> roBman
>
>
Cameron McCormack
> But is there a reason that if it's important it should be stuffed in a
> poorly understood string that flows on every request rather than be
> made available in some kind of web api?
What are the capabilities whose detection are really needed here?
Screen size/resolution, at least, but I don’t know what else. We should
come up with a list of device features people are wanting to key their
page layout/behaviour on and see if Media Queries and other APIs are
sufficient, and if not whether it’s appropriate they’re extended to be.
If we have all our bases covered with these APIs, then I think we should
avoid forcing the device type (which is pretty much just being used as a
proxy for the specific information like screen size) into the UA string.
--
Cameron McCormack ≝ http://mcc.id.au/
Robert Kaiser
> The "Mobile" string in the User Agent indicates that this device would
> prefer a version of the website optimized for Mobile (small form factor
> devices), if available.
The UA or even HTTP at any level is so the wrong tool for this. Media
queries etc. are the right tools here. If I have a desktop that for some
reason is bound to a small-resolution screen, I really want a website
variant that is optimized for the small screen. If I install plain
ubuntu on my phone and run desktop Firefox (yes, some crazy people have
done that), I absolutely want to small-screen-optimized website. If I
attach my TV to my phone and run at 1920x1080 (if that's not supported
on current devices, I'm sure it will come up at some point) then I
absolutely want a large-screen version of the website. Same if I attach
a desktop screen or so.
Which browser or OS you have (and that's what the UA string is for) is
totally the wrong decision criteria. Screen size and available features are.
And I have cursed "mobile-optimized" website a number of times because I
wanted info that I knew where to find on the full website and I couldn't
get to that from my phone.
Didn't we talk about "one web" for mobile and "desktop" some time ago?
Where has that philosophy gone?
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! :)
Boris Zbarsky
> That said, relying on media-queries or JS to do efficient ("just what
> you need, as fast as you can") page loading is challenging.
Any system that involves the server communicating requirements to the
browser and the browser fetching resources based on those requirements
will require one more round-trip than a system which has the browser
communicating capabilities to the server and the server then sending
content based on those.
So if we want to cut out that round-trip, we do have to communicate some
sort of information in response headers.
That said, we _always_ have some version of that round-trip involved, in
that we have the original HTML file. The goal is for that file to link
to exactly the resources the page wants and no more than that, right?
Loading CSS this way is doable, using media queries. We can make it
somewhat more efficient on our end by deferring loads for non-matching
media until later in the document load. See
https://bugzilla.mozilla.org/show_bug.cgi?id=687000
> I haven't figured out how to use media queries alone to effectively load
> different script or CSS
You can't do it for script very easily right now. Maybe we should
change that.
For CSS, you can do it as:
<link rel="stylesheet" href="small-screen.css"
media="(max-width: 200px)">
for example.
> If I need to run a script to decide what other resources to load, I am
> going to largely (or completely) defeat the pre-fetching mechanisms
> built into modern browsers.
Yes, indeed.
> (Actually, if a script sets document.cookie, do we re-fetch resources
> that are pre-fetched?
No.
This is an interesting race condition.... ;)
Of course we also don't refetch them if there's a Set-Cookie header on a
later resource.
> - can we do effective loading of just-what-we-need based on data that
> requires client-side inspection?
I think the answer here is "not yet" at best.
What we would need to do it seems like:
* Fixing bug 687000. This could include possibly having a way to flag
some media queries internally as "will never be true" so we can avoid
loading those stylesheets altogether.... though that will mess with the
CSSOM.
* Adding a way to do useful conditional script loading.
* Adding a way or ways to do useful conditional image loading.
> - what data does that need to be, practically?
This is information that would be good to have, yes.
-Boris
Rob Manson
I think having a clear perspective on how this whole interaction should
work in an ideal world would be an awesome starting point that would
benefit the whole industry. I think the lack of this type of reference
model is one of the main reasons UA sniffing gets abused in the first
place.
I also think Robert Kaiser makes a great point about mobile devices
being used to drive larger and multiple screens like TVs. But this is
definitely not the default behaviour. I think this should be taken into
account in the mapping out of the "ideal reference model" described
above...but this doesn't mean an app can't make an educated guess at
what it should deliver to you first and then if you ask it for something
else or it detects different capabilities then it could adapt. This is
kind of like the device-detection equivalent of progressive enhancement.
In response to David Illsley and Cameron McCormack's points...the reason
device would also be useful is not just about capability mapping. I
know a lot of people will squeal about this comment...but as a web app
developer I see a lot of value in actually knowing what devices are
accessing our apps/sites. If it's just encapsulated to Browser and OS
Platform then I have no insight into the physical form factors that are
influencing the overall UX. I know this can lead to abuse of UA
sniffing...and I know as browser developers you want to do what's "right
for the web"...but this is also a valid need from the web developers
perspective.
As for Robert Kaiser's comments about "one web"...well I do like that
ideal but I'd argue that it's not even "one web" on the PC
platform...and mobile devices are driving fragmentation and Android is
driving this the hardest. Responsive web design is a great starting
point for this but in this fragmented world it's just not the final or
only answer. There are different UX needs and opportunities on
different devices and in different contexts and users crave apps that
elegantly take advantage of this.
roBman
On Wed, 2011-09-21 at 16:44 -0400, Mike Shaver wrote:
> > But is there a reason that if it's important it should be stuffed in a poorly understood string that flows on every request rather than be made available in some kind of web api?
>
> HTTP headers. It costs every HTTP request, it's clumsy.
> That said, relying on media-queries or JS to do efficient ("just what
> it can be the same for everything). I can see how to do it via
> script, but that seems like it's pretty painful, and can hurt
> performance. To wit:
> If I need to run a script to decide what other resources to load, I am
> going to largely (or completely) defeat the pre-fetching mechanisms
> so the parser can't read ahead and find them (maybe a little with
> document.write, but not as aggressively as we'd want), or I set a
> cookie for the server to interpret and invalidate whatever *was*
> prefetched.
> (Actually, if a script sets document.cookie, do we re-fetch resources
>
> So:
> - can we do effective loading of just-what-we-need based on data that
> requires client-side inspection?
> time, without ending up in abstraction hell?
>
> Mike
>
Benoit Jacob
> Currently, Firefox Mobile on Android use a UA like this:
> Mozilla/5.0 (Android; Linux armv7l; rv:9.0a1) Gecko/20110920 Firefox/9.0a1
> Fennec/9.0a1
>
> Note: It mentions "Android" and "Fennec"
>
> Web developers have been filing bugs for a while now to have Mozilla add
> information about the device to the UA.
OT but possibly relevant experience: in WebGL, developers have been
pushing us to implement a function in the spec that returns a UA-like
string describing the GPU, we've been opposing that, and recently we
reached consensus in the WebGL WG to remove that.
It's very important to listen to developers but sometimes what they
ask for is not the best way to do what they want. UA-like strings need
to be parsed, matched against arrays of known devices... this is far
from a perfect solution from a webdev's perspective.
I don't know the specifics of your case but I'd really encourage you
to work with developers to figure what exactly they are trying to do.
For example (just an intentionally bogus example) if the reason why
they need device information is that they need to know the amount of
RAM on the device, then instead of a UA string they would be better
served by adding a function to query the RAM size.
Some more possibly useful thoughts:
1) If you're looking for an ally in pushing back against UA string
stuff, try to get Opera in the conversation. They hate UA strings even
more than we do. Happened in the WebGL discussion.
2) beyond the UA issue there is the privacy/fingerprinting issue
associated with exposing any device info. In the WebGL case we've
learned that our best approach was to be pragmatic with that: find the
best possible *compromise* between usefulness and exposing more
information, try to figure exactly what info is useful to expose. To
carry on the bogus RAM size example, if 10 devices have the same
amount of RAM, then exposing the device name is exposing useless
fingerprinting information and that's fixed by exposing RAM size
instead. Sticking to a hard line of "we won't expose any information"
is not always a very solid standpoint as many useful features are
indirectly exposing some information anyway, so we've already been
making compromises for a long time.
Cheers,
Benoit
> We have been pushing back, saying UA
> sniffing is not good for the web and that there are client side ways of
> detecting physical constraints.
>
> Now that we have build of Firefox that work really well on Android tablets,
> we see a new request: Can we get different content for tablet vs. phone?
>
> We still only support the above UA for tablets and phones, so web properties
> can't UA sniff for this difference either. We end up with many bugs filed
> for individual websites looking badly in Firefox, for both phone and tablet.
>
> Google actually has a guideline for UAs on Android:
> http://android-developers.blogspot.com/2010/12/android-browser-user-agent-issues.html
>
> <quote>
> Currently, Android devices provide the following (in addition to standard
> info) in the User-Agent: "Android", a version number, a device name, a
> specific build, Webkit version info, and "Mobile"
>
> The "Mobile" string in the User Agent indicates that this device would
> prefer a version of the website optimized for Mobile (small form factor
> devices), if available.
>
> We recommend that manufactures of large-form-factor devices (where the user
> may prefer the standard web site over a mobile optimized version) remove
> "Mobile" from the User Agent (and keep the rest of the User Agent as
> currently implemented). Web sites can then key off "Mobile" in the User
> Agent to decide on which UI version to present to the device.
> </quote>
>
> If we wanted to follow this same concept, we could:
> 1. Add "Mobile" for small form factors
> 2. Add <device> all the time
>
> Any thoughts on making a change like this? This would probably be for Mobile
> only. I don't think desktop UA would need to be changed.
Henri Sivonen
> Now that we have build of Firefox that work really well on Android tablets,
> we see a new request: Can we get different content for tablet vs. phone?
>
> We still only support the above UA for tablets and phones, so web properties
> can't UA sniff for this difference either. We end up with many bugs filed
> for individual websites looking badly in Firefox, for both phone and tablet.
I think the fundamental problem isn't that tablet and phone aren't
distinguishable from each other in the UA string but that they are
distinguishable from desktop in the UA string. If we showed the same
UA string across desktop, laptop, tablet and phone, Web authors would
have to sniff what they really care about (screen size relative to
text size, availability of touch events).
> If we wanted to follow this same concept, we could:
> 1. Add "Mobile" for small form factors
That might be jumping from the frying pan into the fire.
Opera Mobile doesn't say "Opera Mobile" in its UA string even though
that's the product's name. On tablets (dunno what's the definition of
"tablet" for Opera; Galaxy Tab 10.1 is one), it says "Opera Tablet" in
the UA string even though the user-facing branding is "Opera Mobile".
On phones, it says "Opera Mobi". Opera's UA string on mobile is so
crufty that I can't believe they are optimizing 2 bytes off the
string. I'm guessing they say "Mobi" instead of "Mobile" to avoid
sniffers that look for "Mobile" and decide that anything that's
"Mobile" need dumbed-down content.
If Opera avoids putting "Mobile" in the UA string, chances are that we
should, too.
Speaking of toxic substrings, I think we should seriously consider not
putting the substring "Android" in the UA string. If making the
Android UA string indistinguishable from desktop Linux falls outside
the Overton Window, I think we should say e.g. "Andr" instead of
"Android" to avoid sites assuming that Firefox is WebKit or that
Firefox should get a dumbed-down "mobile" site. I think removing
"Fennec" would be good, too, to make it harder to sniff mobility from
the UA string and to make authors use Media Queries.
(I'm running Nightly on Galaxy Tab 10.1 with the UA string faked to be
desktop Linux on x86_64. This improved my Twitter experience
significantly. However, it seems that e.g. OMG! Ubuntu sniffs for
unfaked properties on the navigator object and still gives me a
dumbed-down version of the site.)
> 2. Add <device> all the time
I think we shouldn't do this for two reasons:
1) Fingerprinting
2) Letting authors sniff by device name is even worse than by letting
them sniff by device class. There's no way the long tail of Web sites
will be maintained enough to keep knowledge of all possible devices
up-to-date and, realistically, sites won't know about all possible
devices to begin with. Letting authors sniff by device name would hurt
users. Either the site does something really nice for some the devices
it knows about and discriminates against users of other devices or the
site does something really clueless for devices in it's list of
"mobile" device names and makes the experience bad on fully-capable
browsers that are running on devices that sniff as "mobile".
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Gervase Markham
> If we wanted to follow this same concept, we could:
> 1. Add "Mobile" for small form factors
thread on both sides.
> 2. Add <device> all the time
idea, for a number of reasons:
- The effects on web compat of increased UA differentiation are almost
always negative
- Some sites will work better on more popular devices (those coded
for), perpetuating market leader advantage and reducing choice
- It's several additional bits of fingerprinting information
Gerv
Rob Campbell
On 2011-09-21, at 11:52 , Mark Finkle wrote:
>
> If we wanted to follow this same concept, we could:
> 1. Add "Mobile" for small form factors
3. Replace "Mobile" with "Tablet"?
As mentioned by Rob Manson, you don't necessarily always want the desktop web experience on a tablet. They're a different class of device, usually with bigger screens, bigger keyboards and different capabilities than either phones or desktops.
iOS devices can differentiate phones from tablets by looking for iPad vs. iPhone/iPod* and we're starting to see some sites tailoring their pages to those specific devices. We should make it possible too.
~ rob
* see, http://www.htmlgoodies.com/beyond/webmaster/toolbox/article.php/3888106/How-Can-I-Detect-the-iPhone--iPads-User-Agent.htm
Henri Sivonen
> If we wanted to follow this same concept, we could:
> 1. Add "Mobile" for small form factors
> 2. Add <device> all the time
both these changes.
I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=700595 as a
follow-up for removing the Fennec token in the light of the Mobile
token.
Mark Finkle
sniffing for native apps too: Android Market.
The Android Market supports a wide variety of filtering options based on
device characteristics, allowing the developer to "send down" the APK
tailored to the device.
That said, the native app also support many client-side ways of
adjusting it's behavior and styling to the device as well.
Mark Finkle
> On Wed, Sep 21, 2011 at 5:52 PM, Mark Finkle<mark....@gmail.com> wrote:
>> If we wanted to follow this same concept, we could:
>> 1. Add "Mobile" for small form factors
>> 2. Add<device> all the time
>
> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=671634 landed with
> both these changes.
>
> I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=700595 as a
> follow-up for removing the Fennec token in the light of the Mobile
> token.
on the code, and land it again, we can figure out if removing the
"Fennec" token is something we can do. I can't think of any reasons we
really need to keep it.
We do need to consider other mobile platforms currently shipping Fennec
(or something built like Fennec) to make sure the UA presented on those
platforms is "mobile" enough. Bug 671634 only really covers Android at
the moment.
Henri Sivonen
> On 11/08/2011 04:34 AM, Henri Sivonen wrote:
>>
>> On Wed, Sep 21, 2011 at 5:52 PM, Mark Finkle<mark....@gmail.com>
>> wrote:
>>>
>>> If we wanted to follow this same concept, we could:
>>> 1. Add "Mobile" for small form factors
>>> 2. Add<device> all the time
>>
>> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=671634 landed with
>> both these changes.
>>
>> I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=700595 as a
>> follow-up for removing the Fennec token in the light of the Mobile
>> token.
>
> It seems the patch was backed out as well. Once we get a security review on
> the code, and land it again,
name part doesn't land again.
> we can figure out if removing the "Fennec"
> token is something we can do. I can't think of any reasons we really need to
> keep it.
Mark Finkle
Mark Finkle
>> If we wanted to follow this same concept, we could:
>> 1. Add "Mobile" for small form factors
>> 2. Add<device> all the time
>
> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=671634 landed with
> both these changes.
>
> I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=700595 as a
> follow-up for removing the Fennec token in the light of the Mobile
> token.
really need to keep it.