Camino User-Agent string
Gervase Markham
Firefox version number of the closest Firefox release.
https://bugzilla.mozilla.org/show_bug.cgi?id=384721
They want to do this because a number of sites sniff for "Firefox".
This is somewhat controversial, because historically the Mozilla
project's line on browser sniffing has been:
1) Don't sniff at all
2) If you must sniff, use object sniffing
3) In the rare cases that doesn't work, use the Gecko version
Changing Camino would be construed as giving up on that line. So it was
requested in the bug that a discussion be started.
Some questions it might help to consider when assessing the scale of the
problem:
- Is it OK if a site warns you that your browser has not been tested,
but allows you to continue anyway?
- What about sites (e.g. banks) for which lack of support for Camino is
a deliberate policy?
- Does it matter how serious the problem is? I.e. total site blockage
vs. lack of flyout submenus on msnbc.com?
Useful documents for the discussion
-----------------------------------
Tracking bug for sites which sniff for "Firefox":
https://bugzilla.mozilla.org/show_bug.cgi?id=334967
(Note: not all bugs in this list are relevant here - e.g. some correctly
exclude Camino, like rollyo.com, bug 337056)
We have a specification for user agent strings:
http://www.mozilla.org/build/revised-user-agent-strings.html
Various Mozilla pages on the topic:
http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support
http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko
Advocacy site on the topic:
http://geckoisgecko.org/
Gerv
smorgan
explanation of how this is a layout issue. David Baron made the
assertion that this is a content handling issue, and thus outside the
jurisdiction of the Camino team, but I'm having a hard time
understanding how our user agent could be construed to affect the
handling of any given web content.
If people want to discuss whether their opinion is that it's a good
idea or not, in an academic sense, that's fine, but if the discussion
is going to be framed in terms of whether or not we are allowed to
make this change, someone first needs to provide a compelling argument
why the decision of Mike Pinkerton and myself (the Camino module
owners) is not relevant.
Samuel Sidler
> The Camino team would like to change their user agent string to add the
> Firefox version number of the closest Firefox release.
> https://bugzilla.mozilla.org/show_bug.cgi?id=384721
> They want to do this because a number of sites sniff for "Firefox".
s/would like to/is going to
(see below)
> This is somewhat controversial, because historically the Mozilla
> project's line on browser sniffing has been:
>
> 1) Don't sniff at all
> 2) If you must sniff, use object sniffing
> 3) In the rare cases that doesn't work, use the Gecko version
Camino's not changing the Mozilla project's view of browser sniffing.
Not in any way should this be misinterpreted to mean that any Camino
team member believes those ideals aren't true.
> Changing Camino would be construed as giving up on that line. So it was
> requested in the bug that a discussion be started.
Camino is a mozilla.org project, yes, but it's also it's own project
with it's own rules and it's own UA that can be changed at will (see my
comments on the spec below) by the Camino team.
> Some questions it might help to consider when assessing the scale of the
> problem:
>
> - Is it OK if a site warns you that your browser has not been tested,
> but allows you to continue anyway?
My answer would be "hell no". There is no way it's OK. Maybe it is for
you, but for end-users, this experience sucks. I think (hope) we can all
agree with that.
> - What about sites (e.g. banks) for which lack of support for Camino is
> a deliberate policy?
Until we try it, as the bug mentions, we have no way of knowing what
portion of the web legitimately blocks Camino. That's what this change
is: a trial. If it's a failure then we can back out the change. But my
suspicion is that it won't be.
> - Does it matter how serious the problem is? I.e. total site blockage
> vs. lack of flyout submenus on msnbc.com?
To you, maybe it matters. To a user? Definitely not. Do we care about
users here or developers? If a user were to download Camino, go to
msnbc.com, and see that it didn't perform as well as Firefox or Safari,
they'd switch back and give up on Camino, especially if they use
msnbc.com five hours a day (or some other large number).
> Tracking bug for sites which sniff for "Firefox":
> https://bugzilla.mozilla.org/show_bug.cgi?id=334967
> (Note: not all bugs in this list are relevant here - e.g. some correctly
> exclude Camino, like rollyo.com, bug 337056)
Not all of these are about Camino, no. But I think they show the greater
issue... more comments below.
> We have a specification for user agent strings:
> http://www.mozilla.org/build/revised-user-agent-strings.html
The proposal that currently exists follows the spec and I doubt any
Camino team member wants to violate that spec. The proposal adds a
"vendor comment" to Camino's UA. The Camino project is the vendor here,
led by the module owners of Camino.
(Note that other browsers *have* violated the spec. See comment 22 of
bug 384721.)
> Various Mozilla pages on the topic:
> http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support
>
> http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko
>
> Advocacy site on the topic:
> http://geckoisgecko.org/
>
> Gerv
The true issue above is that web developers aren't looking for Gecko.
The real world isn't inline with our ideal world. It's no one person or
organization's fault, but it *is* the reality we live in today. The web
today looks for Internet Explorer and Firefox, with a few websites still
checking for Netscape and some even being kind enough to look for other
specific user-agent strings. Sure, there are many, many web developers
who specifically check for a Gecko rv or even do a check for specific
features that a browser supports. It's clear that a good portion of
sites don't do that, however. It's easier for them to check for specific
browsers they want to support.
(And, I'll concede that maybe it's not easier -- I honestly don't know
-- but that appears to be the perception of a majority of web developers.)
Camino here has decided that in more cases than not, we're exactly the
same as Firefox and should be treated as such. We won't know until we
ship some builds (nightly, not releases) with our vendor comment added
and see what breaks. I'm guessing that the reported bugs for this will
be far less than the reported bugs for sites "not support Camino" when
in reality they could.
We all know this sucks. Gerv, you know it sucks. I know it sucks. David
knows it sucks. The entire Camino team dislikes it. But our users are
crying for it, whether they realize it or not. Is there another
short-term solution? Point me to one.
In the long-term, what can we do? How do we make web developers more
responsible?
One idea is to rethink the idea of a user-agent string. What information
in a UA is actually important? If we want web developers to check based
on the Gecko rv in the UA instead of the product name, why do we ship
the product name in the UA at all? I can see marketing reasons (market
share, etc), but are there technical ones? What if we shipped a release
with only "Gecko/20070515 rv:1.8.1.4" as it's user-agent? How much of
the web would break? We've seen time and time again that web developers
even check what operating system you're running. Now, we all know that
Firefox is (mostly) the same on all platform, but apparently they don't.
(Note that the idea above would require us to either break or modify the
user-agent string specification, which I fully understand.)
Another idea (credit to timeless) is to ship an extension (on by
default) with Firefox that changes the product name in the UA randomly.
We could, for fun, change other parts of the UA, thus requiring web
developers to check specifically for the part that doesn't change: the
Gecko rev and information.
I bet, in the above scenario, the web would break in some pretty serious
ways. Would developers respond? How fast? How long did it take for them
to start supporting Firefox in the first place? I can imagine the lag
wouldn't be as long as previously, but I bet it'd be significant.
In comment 25 of bug 384721, David says the following:
> Firefox owners don't make arbitrary changes to Gecko over the
> objections of Gecko module owners; I don't see why Camino should
> be different.
To that, I'd assert that if either of the ideas I mentioned above (or
something similar) were proposed by Gecko module owners, neither would
get implemented. Either one could (would?) help improve the overall web,
but could also potentially hurt Firefox (again, from a marketing
standpoint). If my assertion is incorrect, I'd like to be proven wrong.
The reason I believe this is true is because the user-agent string is
partially up to the product and not entirely up to Core.
The change proposed in bug 384721 is a win for Camino's users and a loss
for the web overall. It's sad, but I believe it needs to be done to
improve overall user experience.
--
Samuel Sidler
The Camino Project
Boris Zbarsky
> This is somewhat controversial, because historically the Mozilla
> project's line on browser sniffing has been:
>
> 1) Don't sniff at all
> 2) If you must sniff, use object sniffing
> 3) In the rare cases that doesn't work, use the Gecko version
We haven't been very good at pushing this line, in my opinion, certainly not the
third item. Does the Mozilla Foundation have evangelists on staff who go to
sites and tell them that the Firefox developers say not to sniff for "Firefox"?
Or are we hoping that site authors will listen to Camino, etc. users or
developers who complain? If so, that's a silly hope, in my opinion.
> - Is it OK if a site warns you that your browser has not been tested,
> but allows you to continue anyway?
It's better than the alternative of not allowing access at all, but definitely
sub-par.
> - What about sites (e.g. banks) for which lack of support for Camino is
> a deliberate policy?
I can't think of a good reason for this policy, to be honest.
> - Does it matter how serious the problem is? I.e. total site blockage
> vs. lack of flyout submenus on msnbc.com?
Probably not to users, no.
I really wish we _did_ randomize the product name from the very beginning, or
not ship one at all. I think the fact that we have by-default undermines our
attempts to evangelize point #3 above, even if we were trying to it. Which we
aren't, that I can see.
-Boris
-Boris
Gervase Markham
> We haven't been very good at pushing this line, in my opinion, certainly
> not the third item. Does the Mozilla Foundation have evangelists on
> staff who go to sites and tell them that the Firefox developers say not
> to sniff for "Firefox"? Or are we hoping that site authors will listen
> to Camino, etc. users or developers who complain? If so, that's a silly
> hope, in my opinion.
I agree. I think that a quid pro quo for asking the Camino team not to
do this, would be finding some TE resource to deal with this specific
problem.
>> - What about sites (e.g. banks) for which lack of support for Camino
>> is a deliberate policy?
>
> I can't think of a good reason for this policy, to be honest.
Perhaps not. But we don't know about their internal browser verification
and security processes. In at least one case, a bank representative has
got a Bugzilla account and interacted with developers in the bug,
explaining why it works the way it does.
> I really wish we _did_ randomize the product name from the very
> beginning, or not ship one at all. I think the fact that we have
> by-default undermines our attempts to evangelize point #3 above, even if
> we were trying to it. Which we aren't, that I can see.
So perhaps the right thing to do is to remove the Firefox name from the
UA string? If Firefox itself did it, the web would need to pay attention.
Gerv
Gervase Markham
> Changing Camino would be construed as giving up on that line. So it was
> requested in the bug that a discussion be started.
My view: up to now, UAs have been in continuous retreat, with greater
lengthenings. First there was Mozilla/X.X - but then too many people
sniffed that, and so it got stuck. And so on.
At last, we've finally figured out that what people should be looking
for is rendering engines, not browser versions. WebKit has WebKit/foo,
Gecko has Gecko/bar, and so on. This has the potential to stop this
ridiculous ever-lengthening UA string problem.
It would be a great shame to give up on that for the sake of a small
handful of sites. And it is a small handful - the bug in question had 29
dependencies last time I looked, and not all of them are relevant to Camino.
On the other hand, as I said in another message, we need to do better
than just tell the Camino team to suck it up. And I hope we can come up
with a plan for that.
Gerv
Gervase Markham
> Camino's not changing the Mozilla project's view of browser sniffing.
> Not in any way should this be misinterpreted to mean that any Camino
> team member believes those ideals aren't true.
"These are my principles. If you don't like them, I have others"?
There's no point having ideals if you abandon them in practice; you are
just showing they aren't actually your ideals.
You can disagree with the project's policy if you like; but you can't
both agree with it and propose what you are proposing.
> Camino is a mozilla.org project, yes, but it's also it's own project
> with it's own rules and it's own UA that can be changed at will (see my
> comments on the spec below) by the Camino team.
I think that the collision of "Camino is a mozilla.org project" and
"Camino is its own project" is what has led to this debate. Exactly
where the UA string falls in that is the question at hand.
>> - Is it OK if a site warns you that your browser has not been tested,
>> but allows you to continue anyway?
>
> My answer would be "hell no". There is no way it's OK. Maybe it is for
> you, but for end-users, this experience sucks. I think (hope) we can all
> agree with that.
Why so, if it's the truth? Camino is not Firefox - you would be the
first to admit that - and so it's possible that there will be things
that work in Firefox but don't in Camino. Perhaps you have come across
them yourselves in your bug fixing.
>> - What about sites (e.g. banks) for which lack of support for Camino
>> is a deliberate policy?
>
> Until we try it, as the bug mentions, we have no way of knowing what
> portion of the web legitimately blocks Camino.
I don't understand how your point follows from my question. I was
talking about banks who have specifically told us they are blocking
Camino - no UA string change is required to find this out.
How does changing the UA help you distinguish between a legitimate and
an illegitimate block?
>> We have a specification for user agent strings:
>> http://www.mozilla.org/build/revised-user-agent-strings.html
>
> The proposal that currently exists follows the spec and I doubt any
> Camino team member wants to violate that spec.
I didn't imply that it didn't; I linked to it, if anything, to show that
it didn't.
> (Note that other browsers *have* violated the spec. See comment 22 of
> bug 384721.)
If those other browsers are not part of the Mozilla project (again, the
same question arises), then their behaviour cannot be something we worry
about.
> The true issue above is that web developers aren't looking for Gecko.
Sorry, but that's rubbish. If all we have are 29 sites which are broken,
then the fact is that the vast majority of web developers _are_. Find
any of the new DHTML Ajax libraries, used to build hundreds of sites.
They all check for Gecko, and I assume they work fine in Camino.
> One idea is to rethink the idea of a user-agent string. What information
> in a UA is actually important? If we want web developers to check based
> on the Gecko rv in the UA instead of the product name, why do we ship
> the product name in the UA at all?
That's a very, very good question.
> I can see marketing reasons (market
> share, etc), but are there technical ones?
If people want to judge market share, we can make sure that each release
we do has a slightly unique Gecko date (a day apart or whatever). Then
stats people can distinguish, although most people won't care. Because
the date would change with every sub-release, people would never look
for specific dates for sniffing purposes. They could still do >=, but
we're fine with that.
> (Note that the idea above would require us to either break or modify the
> user-agent string specification, which I fully understand.)
Hey, we wrote it :-) Of course, there's parsing code out there. So we
need to be careful. But with warning, we might be able to come up with
something.
Gerv
smorgan
> then the fact is that the vast majority of web developers _are_.
We have a lot more than that. I've been answering reading Camino
feedback, forums, etc. for a very long time. I always tell users to
complain to the sites' admins, but I don't file TE bugs on every
single on of those sites, because I don't have the time to spend
filing bugs that will either sit and rot with no action taken, or in
some cases be closed as (essentially) "we don't care about sites that
are sniffing".
As for sites that want to choose to block Camino explicitly, there's
nothing stopping them from doing so after we change our UA, as it will
still contain the word Camino. This way, they'll just have to actually
decide to do it, rather than blocking us by omission.
fantasai
I think the idea of removing Firefox from the version string is a
possible solution to this. We could do that for Firefox 3, starting
with the next alpha. As a major release, and a major rev in Gecko,
it will get plenty of attention. We can have some people write web
developer articles on our UA sniffing policy and why we have it
("keeping the web open" and "preserving choice and innovation"!) and
how to check for Gecko in the UA string, and publish those over the
summer, to make sure more web developers sit up and pay attention.
I'm volunteering right now to provide editorial review to anyone who
does that. :)
If we find that the Web really can't take it, we can put Firefox
back in the UA string with the first post-3.0 security release and
let Camino do the same.
Meanwhile, let's see if this can get webmasters to fix their sniffing
code. This is totally in line with our overall mission as an organization;
I think we should try it.
~fantasai
smorgan
> I think that the collision of "Camino is a mozilla.org project" and
> "Camino is its own project" is what has led to this debate. Exactly
> where the UA string falls in that is the question at hand.
Once again, I would like an explanation of why there is a question.
It's a change within the Camino portion of the tree, it has absolutely
no direct effect on any other product or shared component, it violates
no web standards, and we have been told there are no legal issues.
It's fantastic that this has sparked discussion of having real weight
put behind the evangelism effort, and we (the Camino team) will
certainly watch where this discussion goes and adjust our plans
accordingly--as Sam said, all of us would rather see the need for this
kind of hack to go away, rather than using the hack--but these
repeated vague claims that somehow the standard module ownership
system does not apply here, without any explanation of why (and again,
why is this in m.d.t.layout?) are really frustrating.
If you'd like to discuss this offline that's fine, but unless someone
can give a substantive argument it would be very helpful if this
discussion could stop being framed in terms of the community's right
to dictate Camino policy to the Camino developers and owners.
Smokey Ardisson
> Gerv wrote:
> > Sorry, but that's rubbish. If all we have are 29 sites which are broken,
> > then the fact is that the vast majority of web developers _are_.
>
> We have a lot more than that. I've been answering reading Camino
> feedback, forums, etc. for a very long time. I always tell users to
> complain to the sites' admins, but I don't file TE bugs on every
> single on of those sites, because I don't have the time to spend
> filing bugs that will either sit and rot with no action taken, or in
> some cases be closed as (essentially) "we don't care about sites that
> are sniffing".
Just to reiterate what Stuart said here, bug 334967 is just the tip of
the iceberg. Its deps are either TE bugs that were originally filed
against Camino and which I added to the tracking bug when I learned of
it, other TE bugs I've happened upon randomly when searching for
something someone's reported and which matched the issue, and a few
bugs added by other (non-Camino) triagers who happen to know about the
tracking bug. To my knowledge, no-one's made any concerted effort to
go through open TE bugs and pull out all the sniffing-related ones
that have been filed since TE was opened. Moreover, every site that
sniffs and gets filed in Bugzilla doesn't get kicked to TE; rather
than flood TE with so many bugs that the major sites get lost in the
noise (or, lost more than than they are now in the morass that is TE),
many just get closed INVALID.
By contrast, I think we see about 1 site per week in the Camino forum
(and I don't read the feedback list, but I'd guess it's at least that
there, too). As Stuart notes, we always request people write to
webmasters and point them at http://www.geckoisgecko.org (started by a
Camino user, btw).
I'm delighted to see interest in actually doing something about the
problem of sniffing, but it's going to need some serious commitment
from those who care about Gecko and have resources and clout to
leverage.
For example, I would have loved to see outrage (and education efforts)
from the organization that shepherds Gecko when http://developer.yahoo.com/yui/articles/gbs/
first came out in early 2006; it was a squandered opportunity to push
"rendering engines" instead of "browsers" (that page illustrates
everything that is wrong with people who *think* they're actually
performing best-practice detection these days, and if you send
different code to different browsers [based on rendering engines],
what code do you send to X-grade browsers? Gecko code? WebKit code?
Random generic code?). Instead, we're left with a situation where
Yahoo properties work correctly with Firefox but not other Gecko
browsers, and each different property has to be evangelized separately
(and, really, for each browser on each property, since they tend to
ignore "sniff for rendering engine" and just add each new complaining
browser, when they deign to add at all). As I recall, the BBC
announced a very similar policy at the same time. We can complain,
but since we're not Firefox (or Safari, or IE), not A-Grade browsers,
it doesn't really matter.
And, as I mentioned in bug 334967 when I introduced
http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko , the existing
"when and how to sniff" documentation in
http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support
is in need of a serious upgrade. Too much time and effort is spent on
differentiating Mozilla from Netscape 4, and the amount of time the
document spends on describing sniffing for different UA string
components seems to run counter to the goals of no sniffing/feature
sniffing/rendering engine and engine version sniffing trio (which
aren't, in my opinion, adequately stressed in that document). As I
said in the bug, I'm not the right person from a technical perspective
to write or revise the doc, but I'm happy to help, and rather than
simply complaining, I did draft http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko
as an idea of what I think would be better (also, thanks to Boris for
the edits he made).
Also, once the existing sniffing document is fixed (or replaced), it
(or its successor) needs its visibility raised; you can only find that
page in DevMo if you're specifically looking for it, which seems less-
than-helpful if we want to promote "no sniffing" as our first ideal.
But all of this takes time, both in person-hours and, worse, in
lifespans of old ideas. In the absence of any meaningful efforts on
the sniffing-education front now (or, really, in the last four years)
by those with leverage, we need to do what's best for Camino users
right now. That we have to, and what we need to do to do that,
sucks. My hope is that it is only a temporary hack....
Smokey
L. David Baron
> Once again, I would like an explanation of why there is a question.
> It's a change within the Camino portion of the tree,
Only because Gecko provides APIs for the purpose of helping
applications follow
http://www.mozilla.org/build/revised-user-agent-strings.html
> it has absolutely
> no direct effect on any other product or shared component,
It most certainly does, since it increases the pressure on other
non-Firefox Gecko apps to make the same change.
It's also primarily an issue about what we send over the wire to Web
sites, a topic that's primarily a Gecko issue and on which the Gecko
module owners are more likely to be experts.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
smorgan
> Only because Gecko provides APIs for the purpose of helping
> applications followhttp://www.mozilla.org/build/revised-user-agent-strings.html
Which we are doing.
> > it has absolutely
> > no direct effect on any other product or shared component,
>
> It most certainly does, since it increases the pressure on other
> non-Firefox Gecko apps to make the same change.
I used the word "direct" very deliberately. That's an indirect effect,
and all kinds of things have indirect effects on other browsers. As a
concrete example, we get pressure from some users to implement things
like middle-click-to-close-tabs because of Firefox having done it, but
I don't think that means that I should be able to override mconnor
when I disagree with Firefox UI.
> It's also primarily an issue about what we send over the wire to Web
> sites, a topic that's primarily a Gecko issue and on which the Gecko
> module owners are more likely to be experts.
If there is a technical reason that vendor comments are problematic,
then why is there an API for adding them? I haven't heard any
arguments based on technical expertise that we lack, just a difference
of opinions a philosophical issue based on well-established facts that
we all understand.
Andrew Schultz
> So perhaps the right thing to do is to remove the Firefox name from the
> UA string? If Firefox itself did it, the web would need to pay attention.
This seems like a great idea to me. The only good reason I can see to
not do this is that there are some sites that might want to sniff out
the product for the purpose of delivering appropriate extensions (AMO,
Google toolbar, etc). I was discussing this with Sander and he
suggested that the app's GUID be exposed as part of the user agent (or I
guess as another |naviagator| property) so that sites with interest in
delivering extensions could sniff that out (if they're making
extensions, they'd know that anyway). A webmaster that really wanted to
sniff out firefox and block non-firefox apps could still do so, but it
would be harder and perhaps too hard for the low-IQ webmasters that
typically use sniffing now. I guess some "helpful" person might still
add GUID sniffing as part of a larger browser sniffing JS library and
then we're back to square one.
Anyway, as a user and developer of SeaMonkey (which is as far as I know
afflicted by all the same boneheaded sites that Camino is), I would
oppose putting Firefox in the UA (like Firefox? I hope not!). And I
would welcome the removal of the product name from the UA.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Adam Hauner
> At last, we've finally figured out that what people should be looking
> for is rendering engines, not browser versions. WebKit has WebKit/foo,
> Gecko has Gecko/bar, and so on. This has the potential to stop this
Gecko/bar is not too useful without rv:foo on other side of user-agent
string, because bar is just build date. Build date is same for builds
from different branches: if I'll build tomorrow from 0.9.1, 1.0.0, 1.4,
1.7, 1.8, 1.8.1 and trunk, all builds will have "Gecko/20070623".
best regards
--
Adam Hauner
Projekt CZilla
http://www.czilla.cz/ - http://start.czilla.cz/
http://firefox.czilla.cz/ - http://thunderbird.czilla.cz/
Adam Hauner
> I really wish we _did_ randomize the product name from the very
> beginning, or not ship one at all. I think the fact that we have
> by-default undermines our attempts to evangelize point #3 above, even if
> we were trying to it. Which we aren't, that I can see.
Just for curiosity...
In reality, product name of Firefox *is* randomized over its user base.
For example this is detection code for one version of Firefox on web
traffic analysis service:
<pattern>^Mozilla/5\.0 \(.*\) Gecko/.*(Firefox|BonEcho)/2\.0\.0\.4</pattern>
<pattern>^Mozilla/5\.0 \(.*\) Gecko/.*
(Butt|Fire|Free|Hidden|...|Sun|...|Thunder|Turbo|Water|Web)(aardvark|adder|...|bird|...|worm|yak|zebra)/2\.0\.0\.4</pattern>
// "..." stands for really long list of variants provided by
// Firesomething extension
<pattern negative="1">^Mozilla/5\.0 \(.*\)
Gecko/.*(Sun|Thunder)bird/</pattern>
<pattern
negative="1">Madfox/|Galeon|Epiphany|Flock|Firescape|Iceweasel|Navigator</pattern>
Marek Stępień
> Gervase Markham wrote:
>> So perhaps the right thing to do is to remove the Firefox name from
>> the UA string? If Firefox itself did it, the web would need to pay
>> attention.
>
> This seems like a great idea to me. The only good reason I can see to
> not do this is that there are some sites that might want to sniff out
> the product for the purpose of delivering appropriate extensions (AMO,
> Google toolbar, etc). I was discussing this with Sander and he
> suggested that the app's GUID be exposed as part of the user agent (or I
> guess as another |naviagator| property) so that sites with interest in
> delivering extensions could sniff that out (if they're making
> extensions, they'd know that anyway).
A simpler solution, I think, would be to drop "Firefox/x.x.x.x" from the
UA string, but leave the product name in place for other apps (Camino,
SeaMonkey, Thunderbird). Basically, let's re-use the late Mozilla
Suite's UA string for Firefox.
So, imagine we had implemented this solution in 1.8. Firefox 2.0.0.4
with this scheme would just have been:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; pl; rv:1.8.1.4) Gecko/2007051502
but Camino's UA string wouldn't need any changes:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; pl; rv:1.8.1.4)
Gecko/20070509 Camino/1.5 (MultiLang)
This way, stats companies can still easily differentiate between
Firefox and non-Firefox apps (so you won't serve a SeaMonkey extension
to a Firefox user), but ignorant web developers would need to
specifically block Camino or SeaMonkey.
In a sense, this is what Camino developers wanted - full Firefox UA
string in the Camino one. ;-)
--
Marek Stepien
mste...@aviary.pl
smorgan
> > Camino's not changing the Mozilla project's view of browser sniffing.
> > Not in any way should this be misinterpreted to mean that any Camino
> > team member believes those ideals aren't true.
>
> "These are my principles. If you don't like them, I have others"?
>
> There's no point having ideals if you abandon them in practice; you are
> just showing they aren't actually your ideals.
>
> You can disagree with the project's policy if you like; but you can't
> both agree with it and propose what you are proposing.
If this is true, then everyone on the entire Mozilla project who ever
worked on quirks mode compatibility bugs doesn't believe that
standards-compliance is a good thing for the internet. Is that your
assertion?
Chris Thomas
> Anyway, as a user and developer of SeaMonkey (which is as far as I know
> afflicted by all the same boneheaded sites that Camino is), I would
> oppose putting Firefox in the UA (like Firefox? I hope not!).
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/20070620
SeaMonkey/2.0a is better than Firefox/3.0a4" ;)
Chris
Seo Sanghyeon
> Sorry, but that's rubbish. If all we have are 29 sites which are broken,
> then the fact is that the vast majority of web developers _are_.
As Microsoft is now shipping a JavaScript file checking for Firefox
instead of Gecko, you can expect the number of sites to multiply:
https://bugzilla.mozilla.org/show_bug.cgi?id=385720
Seo Sanghyeon
Gervase Markham
> And, as I mentioned in bug 334967 when I introduced
> http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko , the existing
> "when and how to sniff" documentation in
> http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support
> is in need of a serious upgrade.
Go for it. I'm sure Sheppy would love it if you took that page and
spanked it hard.
> As I
> said in the bug, I'm not the right person from a technical perspective
> to write or revise the doc,
Why not? You seem to do pretty well with geckoisgecko.org.
Gerv
Gervase Markham
> If this is true, then everyone on the entire Mozilla project who ever
> worked on quirks mode compatibility bugs doesn't believe that
> standards-compliance is a good thing for the internet. Is that your
> assertion?
No, that doesn't follow, because they are _quirks_mode_ compatibility bugs.
If someone suggests putting compatibility fixes of that sort into
standards mode, there's normally a pretty big pushback. The reason we
_have_ quirks mode is so that we can also have a standards-compliant
mode which does the right thing. If we only had one mode, it would be
much worse for the Internet's standards compliance.
Gerv
Boris Zbarsky
> In reality, product name of Firefox *is* randomized over its user base.
> For example this is detection code for one version of Firefox on web
> traffic analysis service:
Traffic analysis tries to extract versions too, and is paid for based on how
accurate it is, thus has incentive to be as complete as possible. Web sites
just care about the "most common" versions, typically. I would be surprised to
find a site sniffing for "BonEcho", much less "Turboaardvark".
-Boris
Dan Veditz
> Gecko/bar is not too useful without rv:foo on other side of user-agent
> string, because bar is just build date. Build date is same for builds
> from different branches: if I'll build tomorrow from 0.9.1, 1.0.0, 1.4,
> 1.7, 1.8, 1.8.1 and trunk, all builds will have "Gecko/20070623".
Worse is if a Linux vendor builds FF2 from the exact release-tagged sources
today they get an entirely different Gecko/ date. Useless.
The date was intended to say something about the source; it was instead
implemented as a build date since that was easier. For official
Mozilla/Netscape builds the difference was negligible, but when the
published tarballs are used by others they get incorrect results.
UA strings have been biting us for a long time, see
https://bugzilla.mozilla.org/show_bug.cgi?id=65764#c18
from back in the days when we were trying to make the "Mozilla/5.0" part
mean something
smorgan
> No, that doesn't follow, because they are _quirks_mode_ compatibility bugs.
>
> If someone suggests putting compatibility fixes of that sort into
> standards mode, there's normally a pretty big pushback. The reason we
> _have_ quirks mode is so that we can also have a standards-compliant
> mode which does the right thing.
I think it does follow, but I apparently wasn't clear on why:
Web standards currently exist, and have for a while. Clearly we want
authors to create pages using standards, as opposed to continuing to
use non-standard pages. Given that, the arguments for and against
quirks mode are essentially:
Pro: There are pages out there, both old and new, that are not
standard-compliant, and not rendering them in a useful way for the
user creates a bad user experience for users of Gecko-based browsers.
Good quirks-mode rendering lets users use more web pages.
Con: If compatibility of pages that are not standards compliant is
good, then authors have little incentive to fix their broken pages.
Good quirks-mode rendering reduces pressure on authors to do the right
thing.
Good ways of doing client-capability-detection exist, and have for a
while. Clearly we want authors to use them, as opposed to continuing
the practice of checking the browser name. Given that, the arguments
for putting Firefox in other Gecko user agents are:
Pro: There are page out there, both old and new, that are looking for
the word Firefox, and not providing it creates a bad user experience
for users of non-Firefox Gecko-based browsers. Adding it lets users
use more web pages.
Con: If non-Firefox browsers pass the UA checks, then authors have
little incentive to fix their broken pages. Adding it reduces pressure
on authors to do the right thing.
Those are very much parallel, and I really don't think I've
misrepresented either case.
> If we only had one mode, it would be much worse for the Internet's standards compliance.
Agreed, but the analogous action to "one mode" for us to take would be
to remove the Gecko string and version from our UA while adding
Firefox so that sniffing for the word Firefox was the *only* way to
detect Camino. What we are doing will provide a UA that works when
sniffed the recommended way, or when sniffed the wrong way. That seems
very much the same as proving an engine which can render both
standards-compliant content and non-compliant content.
Andrew Schultz
> Web standards currently exist, and have for a while. Clearly we want
> authors to create pages using standards, as opposed to continuing to
> use non-standard pages. Given that, the arguments for and against
> quirks mode are essentially:
> Those are very much parallel, and I really don't think I've
> misrepresented either case.
There are similarities, but there are also substantial differences. The
purpose of quirks mode is "backwards compatibility" with "legacy
browsers". [1] There is a large body of html pages that were written a
long time ago (by internet-time) and it's unlikely the pages will ever
be updated at all (the return on investment would be too low).
Acceptable rendering of this legacy content is the primary purpose of
quirks. The secondary purpose is acceptable rendering of pages using
non-standard features that are in widespread use on the web. In
practice, it's unusual that a quirk doesn't meet both criteria -- gecko
wouldn't include a legacy behavior if it wasn't widely used and the
widespread non-standard behaviors exist primarily because that's what
legacy browsers expected.
Camino is asserting that they should change the UA to include "Firefox"
because some websites have started looking for it (this has probably
been slowly growing for a while). The number of sites doing this is
very small in comparison to the number of sites delivering pages that
gecko interprets in quirks mode.
Beyond that, without quirks mode, nobody would use Gecko since there is
substantial amount of quirks-mode content out there. Without people
using it, there is little incentive to use non-quirks HTML/CSS/JS
coding. By implementing quirks mode, Gecko the net effect is an
/increase/ in demand for standards-compliant pages (this was Gerv's point).
Camino's UA string change would also increase the Camino's user-base.
But it /encourages/ webmasters to not check for Camino since even if
Camino's user base increased, there would be no reason to not continue
checking for "Firefox." And it reinforces the webmasters' broken idea
that they should check for Firefox.
[1] http://www.mozilla.org/docs/web-developer/faq.html#layoutmode
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
smorgan
> /increase/ in demand for standards-compliant pages (this was Gerv's point).
>
> Camino's UA string change would also increase the Camino's user-base.
> But it /encourages/ webmasters to not check for Camino since even if
>Camino's user base increased, there would be no reason to not continue
> checking for "Firefox."
This is exactly the double-standard I was trying to highlight, even
more succinctly stated. You are saying that being tolerant of people
doing the wrong thing discourages people from doing the wrong thing
when Firefox does it, but encourages people to do the wrong thing when
Camino does it.
The rest of your arguments are mostly about numbers; Gervase made a
flat statement that it's impossible to both believe in promoting an
ideal and to implement a workaround that lessens pressure on people to
conform to the ideal, and arguments about the number of sites involved
isn't really relevant to absolutist statements about idealism.
If people want to hold us to a double standard, then they will, and
I'm under no illusions that I'm going to convince everyone that that's
the case here. I just want to be very clear that I see it as such,
since I think that if Gervase is going to make sweeping assertions
about our beliefs in a public forum, our perspective should be clearly
stated.
Andrew Schultz
>> By implementing quirks mode, Gecko the net effect is an
>> /increase/ in demand for standards-compliant pages (this was Gerv's point).
>>
>> Camino's UA string change would also increase the Camino's user-base.
>> But it /encourages/ webmasters to not check for Camino since even if
>> Camino's user base increased, there would be no reason to not continue
>> checking for "Firefox."
>
> This is exactly the double-standard I was trying to highlight, even
> more succinctly stated. You are saying that being tolerant of people
> doing the wrong thing discourages people from doing the wrong thing
> when Firefox does it, but encourages people to do the wrong thing when
> Camino does it.
Well, those aren't the words I would use -- there is no
"double-standard." At some point, people considered the existence of
quirks mode and concluded that it would be good for a set of reasons
that are mostly unrelated to the current user-agent issue. Are you
actually disputing that claim or just saying "it's not fair!"?
And Camino is doing quirks too. It's not Firefox vs. Camino here as far
as quirks go.
Gervase Markham
> Those are very much parallel, and I really don't think I've
> misrepresented either case.
The way you have put it is an interesting one, and made me think deeply.
After consideration, I think one difference is as follows: the strategy
we are using with quirks mode is what we do when we've lost a battle.
The strategy we have (up to now) been using with user agents is what we
do when we are still fighting.
Marquee might be one example. For several years, we were fighting. We
won in a lot of areas. But the decision was taken that we'd lost in the
Far East, and that we needed to make the compatibility concession. So we
now have (limited) support for marquee. We started off using one set of
tactics, then later we moved to the other set. In other web
compatibility cases, such as e.g. reflecting all IDs into the top-level
namespace (an IE quirk), we haven't had to give in.
So the question comes down to: is this already a battle we've given up
as lost?
In the case of user agent sniffing, we haven't really even been fighting
the battle all that much - and we've still pretty much won it. We can
argue back and forth all day about how many site there are out there
doing the wrong thing, but there are a heck of a lot of sites out there
doing the _right_ thing. And for the others, the fix is pretty simple in
most cases - s/Firefox/Gecko/. So if we took up our swords in earnest,
we might make real progress. I don't think we can call this one lost
just yet. Perhaps that's where we disagree.
I've always argued that telling the Camino team to just suck it up is
not really a good answer. I was hoping we could find some TE resource to
come to your aid, although I admit I haven't yet been successful in that.
---
A further thought: another important difference is the effect on people
authoring _new_ pages. Standards mode has benefits - consistent
rendering and so on - that mean people want to use it. But to do so,
they have to give up their quirks. So even in the "we've lost" mode,
there is a hope for a better future.
However, with the UA change, that's not present. We know from bitter
experience that when things get into general use in UA strings, they get
stuck there. There's no incentive to wean people off bad behaviours.
Gerv
Gervase Markham
> This is exactly the double-standard I was trying to highlight, even
> more succinctly stated. You are saying that being tolerant of people
> doing the wrong thing discourages people from doing the wrong thing
> when Firefox does it, but encourages people to do the wrong thing when
> Camino does it.
I don't think the two are directly equivalent in that way - see the
second point in my previous post. Because being tolerant of quirks in
Firefox does encourage people to do the right thing with new pages -
because we can then have a standards mode which they want to use, which
gives consistent rendering across all browsers. However, being tolerant
of bad sniffing doesn't encourage anyone to do the right thing.
The flaw in the argument above is that one way of "doing the wrong
thing" is not equivalent to the other way of "doing the wrong thing".
> If people want to hold us to a double standard, then they will, and
> I'm under no illusions that I'm going to convince everyone that that's
> the case here. I just want to be very clear that I see it as such,
> since I think that if Gervase is going to make sweeping assertions
> about our beliefs in a public forum, our perspective should be clearly
> stated.
I am not making sweeping statements about your beliefs; I am merely
pointing out that expressing the goodness of a principle while
simultaneously acting against that principle is normally called (and I
know it's an ugly word, and I didn't particularly want to use it in this
discussion) hypocrisy. Perhaps "inconsistent", at least.
Gerv
smorgan
> I am merely pointing out that expressing the goodness of a principle while
> simultaneously acting against that principle is normally called (and I
> know it's an ugly word, and I didn't particularly want to use it in this
> discussion) hypocrisy.
It is indeed an ugly word, and that's the only reason that I hadn't
used it to describe the situation where representatives of the only
organization within the community with the resources and clout to
actually make a difference in this fight, but which--as you are
apparently just now discovering, but has been apparent for some time
to those of us actually on the battlefront--has no apparent interest
as an organization in really helping, tell us from the sidelines that
we have a moral responsibility to the community to keep fighting and
that the problem is just that we haven't been trying hard enough.
Smokey Ardisson
> Smokey Ardisson wrote:
> > And, as I mentioned in bug 334967 when I introduced
> > "when and how to sniff" documentation in
> > is in need of a serious upgrade.
>
> Go for it. I'm sure Sheppy would love it if you took that page and
> spanked it hard.
>
> > As I
> > said in the bug, I'm not the right person from a technical perspective
> > to write or revise the doc,
>
> Why not? You seem to do pretty well with geckoisgecko.org.
GeckoIsGecko.org is run by *a* Camino user, but not by me (I think he
was just inspired by the title of my wiki page).
Smokey
Gervase Markham
> It is indeed an ugly word, and that's the only reason that I hadn't
> used it to describe the situation where representatives of the only
> organization within the community with the resources and clout to
> actually make a difference in this fight, but which--as you are
> apparently just now discovering, but has been apparent for some time
> to those of us actually on the battlefront--has no apparent interest
> as an organization in really helping, tell us from the sidelines that
> we have a moral responsibility to the community to keep fighting and
> that the problem is just that we haven't been trying hard enough.
I am certainly not saying that you haven't been trying hard enough - I
apologise if it came across that way. I don't know if anyone else is
saying that. As I have argued here and elsewhere, I think this should be
higher on the project's list of priorities.
Gerv