Closed Bug 385999 (firefox-ua) Opened 17 years ago Closed 17 years ago

Remove "Firefox" from Firefox's user agent (UA) string

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Firefox 3

People

(Reporter: fantasai.bugs, Unassigned)

References

(
URL
)

Details

In response to discussion on m.d.t.layout centering on bug 384721 and our UA string policy
  <http://www.mozilla.org/build/revised-user-agent-strings.html>
I'm filing this bug to request that the Firefox name and version number be
removed from Firefox's UA string.

I expect to see either
  - This bug FIXED, bug 384721 marked WONTFIX, and the UA string policy
    unchanged
or
  - This bug marked WONTFIX, bug 384721 FIXED, and the UA string policy
    revised to recommend the appropriate Firefox version comment in all
    Gecko browsers
Flags: blocking-firefox3?
I believe that doing this would break quite a few websites.  There is no way to find all the sites this would break and contact them and ask them to update their sites (much less get them to actually update them) before we shipped Firefox3.
(In reply to comment #1)
> I believe that doing this would break quite a few websites.  There is no way to
> find all the sites this would break and contact them and ask them to update
> their sites (much less get them to actually update them) before we shipped
> Firefox3.

I bet you're right. This is discussed (or at least mentioned) in the newsgroup.
Alias: firefox-ua
Target Milestone: --- → Firefox0.9
Here's a link to the thread alluded to in comment 0:

http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/9a2fb4117a52825d/8c76bb4c1b4d7d84
Summary: Remove "Firefox" from UA string → Remove "Firefox" from Firefox's user agent (UA) string
Target Milestone: Firefox0.9 → Firefox 3
If sites care enough about Firefox and its users to start sniffing for "Firefox" in the ua string, they will adapt if we drop that from the ua string, especially since the sites are likely to be still actively maintained, like http://maps.google.com/.
And these sites aren't *that* many: Bug 334967 has 44 open dependencies. If we do this now, and email all of them, they have plenty of time to fix their sniffing code until the release of Firefox 3.
Bug 334967 has 44 *identified* open dependencies. There could be thousands or even millions more. Until such a change is made, we'll have no way of knowing. Additionally, those are just sites that don't let in *some* other browsers. That doesn't mean a site is looking for Gecko and isn't just special casing a bunch of browsers...

(To be clear, I think this change is valuable for the open web, but we don't truly know what its impact will be.)
(In reply to comment #4)
> If sites care enough about Firefox and its users to start sniffing for
> "Firefox" in the ua string, they will adapt if we drop that from the ua
> string, especially since the sites are likely to be still actively
> maintained, like http://maps.google.com/.

If version identification were to happen via the build date + Gecko version, any site which required specific versions would have to update their UA-checking for every minor 3.0.0.x release of Firefox prior to the actual release to avoid complaints.  A site keeping up with this will have to go to ridiculous trouble to do it, and field-deployable frameworks won't do it at all.  Sites which will do this must be willing to track the release process, but if they'll do that they're lost causes.  This change is for sites that would make the change, not for sites that stubbornly won't.

Food for thought: will fixing this bug or fixing bug 47903 cause more problems, taking into account the quality/quantity of documentation on each problem being solved and the mostly-absence of bug 47903 in IE?  Given UA docs and best practices promulgated throughout the web, I'd like to (correctly?) think fixing this bug would cause fewer, and I got the impression a number of content hackers thought that fix was pretty scary from a breaking-sites point of view.
(In reply to comment #6)
> If version identification were to happen via the build date + Gecko version,
> any site which required specific versions would have to update their
> UA-checking for every minor 3.0.0.x release of Firefox prior to the actual
> release to avoid complaints.

Surely not unless they've failed to discover the wonders of the ">=" operator?

Gerv

The build date is useless, since it doesn't mention which branch the build was made from. But sites can look at the Gecko version (rv:1.9a5) and test if it equal or greater than their minimum requirement. We could provide a small script to extract that from the ua string.
(In reply to comment #5)
> Bug 334967 has 44 *identified* open dependencies. There could be thousands or
> even millions more. Until such a change is made, we'll have no way of knowing.

That's not really true; because people browse the web using Camino and SeaMonkey, and trunk versions of Firefox branded as Minefield or Gran Paradiso, we can be pretty confident that there aren't "thousands or millions" of sites out there which will suddenly break. After all, what this bug is really asking for is "when we ship Firefox, don't add "Firefox/3.x.x.x" to the UA string at the last minute" - because after all, it's not normally there.

Of course, there may be some sites that people haven't bothered to file TE bugs about. It would be useful if we could mine the Reporter data to see if we could find some more. CCing Robert.

Gerv


(In reply to comment #7)
> Surely not unless they've failed to discover the wonders of the ">=" operator?

I was addressing the concern of targeting specifically Firefox by checking for an exact build date.

(In reply to comment #8)
> But sites can look at the Gecko version (rv:1.9a5) and test if it
> equal or greater than their minimum requirement.

Hence the "+ Gecko version" in my comment.  :-)

A last concern which comes to mind, although not an impossible one: the so-called "partner builds".  If they're just repacks of the original build with the original build date, all's good.  If they're rebuilds, you've got date skew.  Not difficult to fix, and I think not something that would ever block this if people cared enough, but something to keep in mind.
What removing "Firefox" from the UA string means, though, is that we'll drop out of most UA statistics worldwide.
I think a better idea to deal with uselessly-browser-blocking websites would be something like http://home.kairo.at/blog/2007-06/a_possible_idea_for_user_agents (which is more visible than the similar solution Opera is using).
(In reply to comment #11)
> What removing "Firefox" from the UA string means, though, is that we'll drop
> out of most UA statistics worldwide.

Not necessarily. Unless the statistics-providers wanted to have wildly inaccurate statistics, they'd cope by checking for Gecko instead. If they wanted to be really picky, they might try having date lists to identify specific versions - but the idea is that only stats collectors would go to such trouble, whereas websites would do the Right Thing because it would also be the easier thing.

I'd actually much rather see stats of the following form:
Trident: 71%
Gecko:   19%
KHTML:    5%
Presto:   4%
Other:    1%

Gerv
Have to say, kairo really had some great ideas there! Both with cleaning up the UA once and for all, and implementing the user-maintained list of sites to spoof until they don't do wrong checks.
Hm, a lot of users are proud to have "Firefox/2.0.0.4" in their UA string.
I can't imagine dropping the app name/version from the UA string.  There are plenty of legitimate reasons for knowing what browser you're using, not just what Gecko you're using.  Not necessarily for random content, but for a site offering an extension for Firefox 2.0, they'd want to show alternate content for Camino or Seamonkey or Epiphany.

I don't necessarily buy the conclusion that we can't evangelize the known sites to sniff on Gecko instead of Firefox.  It seems like a sane switch that the sites could easily make without a lot of work, but I don't know what has been tried to date.
If we decide to make this change, there are a number of things we could do that
will help it go more smoothly.
  1. A short MDC document on how to cope with the change: starting with our
     policy as stated by Gerv on the newsgroup, covering the technical changes
     to ua sniffing, and ending with a link to our comprehensive doc on the
     topic
  2. MozCorp putting out a press release announcing the upcoming change for FF3
     and encouraging sites like ArsTechnica and CNET to pick up the story
  3. Someone posting both articles (together) to Slashdot
  4. Encouraging any members of our community who maintain web development
     focused weblogs to post about it.
  5. Asking skilled web developer writer members of our community to contribute
     articles about this topic to web developer sites like A List Apart.

As I said on the newsgroup, I'm willing to put my own editing/writing skills towards helping with this effort.

> The build date is useless, since it doesn't mention which branch the build was
> made from

(We might want to revisit the way we version Gecko; IIRC it was written before
we had Gecko development happening on trunk while major point releases were
being developed on a branch. Back then branches were relatively short-lived,
from an active development pov. But that is a separate discussion.)

> for a site offering an extension for Firefox 2.0, they'd want to show
> alternate content for Camino or Seamonkey or Epiphany.

The proposal isn't to remove the app name/version for other apps, just for Firefox. See http://groups.google.com/group/mozilla.dev.tech.layout/msg/613ba043ea65f605

> Hm, a lot of users are proud to have "Firefox/2.0.0.4" in their UA string.

That's not nearly as important as keeping the web open to all the other Gecko
browsers out there.
If you're truly interested in creating a world where thousands of Gecko browsers may bloom, this is really the only option to let all of them share Firefox's successes.

And as long as it's this simple to sniff for Firefox (when most web authors really only care enough to care about Firefox), they *will* sniff for Firefox and not for Gecko - I'm sure Occam's razor agrees!
This bug should be WONTFIXed (and to jwalden's point, I'm concerned that we should not have fixed bug 47903 -- we'll find out with a beta or release candidate, if not by the final release of Firefox 3, how bad the damage is there).

We need to avoid breaking sites precipitously, whatever we think of their sniffing techniques. We absolutely need to avoid seeming to drop out of competition with IE (the browser; not "Trident") in market share as measured by common log grepping scripts and Zeitgeist/Comscore metrics. We are not going to reform the world to look for "Gecko", because that's not what *most* people care about. They care about the user *agent* -- the browser in full.

Comment 17 asserts that people will sniff for "Firefox" and that's true (let's say it's enough people that we want to evangelize them to sniff for "Gecko"). Still that does not mean we should remove "Firefox".

/be
(In reply to comment #17)
> If you're truly interested in creating a world where thousands of Gecko
> browsers may bloom, this is really the only option to let all of them share
> Firefox's successes.

First, as a practical point: there won't be thousands of Gecko browsers with significant (that is, anywhere near order of 1 in 1000 users, or even 1 in 1e6) market share for each such browser.

Second, as a matter of moral philosophy: an arbitrary Gecko based browser is not *entitled* to share in Firefox's success. What philosophy holds that? Not mine.

Note that this is different from the question of whether Gecko should be what sites sniff for. Of course sites should sniff for "Gecko", most do, the fact that some do not is a fit subject for evangelism, but in any event a thousand browsers based on Gecko are not "owed" a Firefox user-agent string that does not contain "Firefox", any more than a number of WebKit-based browsers are owed a Safari UA string free of "Safari".

I wanted to call this "thousands of Gecko browsers" point out in a separate comment. Probably we should continue in a newsgroup or mail.

/be
(In reply to comment #9)
> That's not really true; because people browse the web using Camino and
> SeaMonkey, and trunk versions of Firefox branded as Minefield or Gran Paradiso,
> we can be pretty confident that there aren't "thousands or millions" of sites
> out there which will suddenly break. After all, what this bug is really asking
> for is "when we ship Firefox, don't add "Firefox/3.x.x.x" to the UA string at
> the last minute" - because after all, it's not normally there.
> 
> Of course, there may be some sites that people haven't bothered to file TE bugs
> about.

First off, I don't see how you can argue that there's nearly enough trunk testing to equal the wealth of regular Firefox users. Even if you throw in some Camino and SeaMonkey users, there's no way enough Firefox-less user-agent testing has happened. The majority of the bugs that have been added to bug 334967 were filed by Camino users. I'd argue that most SeaMonkey users don't browse like "regular" users. They're more advanced (see below). (I mean, they're using SeaMonkey, after all.) Camino users are the only "end" users who file those bugs, and a) there's not enough of them to represent the millions of Firefox users and b) most of them are too basic to even know how to file a bug.

Secondly, with all the disruptive landings that have taken place on trunk, it's often not easy to determine if there's a bug in the site or a bug in Cairo or the reflow branch landing, or, or, or... Not until we get a more stable, "complete" trunk will we be able to tell. In the above cases, trunk users might not file a bug because they know things are broken.

Thirdly, just as SeaMonkey users are more advanced, usually trunk users are as well. They probably don't browse to the MySpace-like sites as often. What percentage do you think use the new Yahoo! Mail (a broken site) vs the percentage of regular Firefox users that do? These users also know workarounds to the issue and could very well be employing them instead of filing TE bugs.

Fourthly, and finally, there have been about a dozen dependencies added to bug 334967 in the last week. That's just because this issue has been escalated a bit and we've started caring. If the issue becomes even more visible, there could be a dozen more a week... or two dozen. You can argue that there's "only" 44, but frankly I don't consider that a valid argument for the reasons given above.

(Just mid-aired with Brendan, but posting this for posterity, regardless of whether this bug gets WONTFIXed or not.)
We are not removing Firefox from the Firefox user agent string. Camino can do what it wants AFAIC
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
If we seriously want to revise the UA we should concentrate on making the Gecko token useful, but that probably waits for Mozilla 2 when there's some serious changes in support that will justify sniffing for new text.
(In reply to comment #19)
> Second, as a matter of moral philosophy: an arbitrary Gecko based browser is
> not *entitled* to share in Firefox's success. What philosophy holds that? Not
> mine.

Arguably, the Mozilla Manifesto, or at least some less-well-defined sense of moral responsibility with the Mozilla community. The fact that what we thought was a minor Camino change turned into the controversy that spawned this bug unquestionably comes down to the opinion that some hold that all the Gecko-based browsers have a responsibility to that ideal which trumps user experience for users of individual browsers.

I'm not saying this to take one side or the other (I've already made my opinion clear in more appropriate places), just to reinforce (for posterity) that this is indeed the central question, and one that there is clearly not widespread agreement about within the community.
Sam: you can't argue both that SeaMonkey users are too advanced to notice bugs and Camino users are too simple to know how to do so. How would any bugs ever get filed? :-) I agree that the amount of trunk users is not the same as the amount of stable users. But trunk users are looking for bugs, whereas stable users aren't. I'm not trying to minimise the problem, I'm only suggesting that it's unlikely that the 44 represent only a tiny fraction of it.

Brendan: your response to the "let a thousand browsers bloom" comment seems over-literal. Clearly, no-one is imagining a thousand different browsers. But what is our point here? Do we still support choice on the Internet when it comes to browsers, or have we decided that, now Firefox is successful, that's no longer a tune we want to sing? Is web compatibility between different UAs about rendering engines, or about which pretty logo is in the chrome? 

People UA sniff (rightly or wrongly) to decide what content to send or which JS branch to take. The content that's sent or the branch taken should depend on the engine, not the pretty logo. So the UA string should tell the site about the engine. Safari got the point here; their UA says "like Gecko", not "like Firefox".

I don't think much of the "we'll drop out of the logs" argument. Are Xitimonitor and friends going to declare to the world with a straight face that IE is now back to having a 96% market share, or are they going to update their counting scripts? (Particularly if we give them six months warning.)

Gerv

(In reply to comment #24)
> Safari got the point here; their UA says "like Gecko", not "like Firefox".
> 

This might be why they have problems on many websites...
(In reply to comment #24)
> Sam: you can't argue both that SeaMonkey users are too advanced to notice bugs
> and Camino users are too simple to know how to do so. How would any bugs ever
> get filed? :-) I agree that the amount of trunk users is not the same as the
> amount of stable users. But trunk users are looking for bugs, whereas stable
> users aren't. I'm not trying to minimise the problem, I'm only suggesting that
> it's unlikely that the 44 represent only a tiny fraction of it.

Gerv: I think you missed my point. SeaMonkey users might notice bugs but work around them because, well, they know how. They're more advanced in knowledge. Some might file bugs on the issue but I'd venture to guess that most don't.

Camino users are simple. They know there's a problem but when then encounter it, they just get frustrated and switch browsers or email our feedback address. It's not that they're stupid, it's that they want the web to Just Work (tm) and will move to a browser that makes that happen (usually Safari for most of their needs).

Obviously, with the above, there are exceptions to both generalizations, as evidenced by the bugs on file.

Trunk users might be looking for bugs, but they're a) looking in all the wrong places (i.e., they use a different set of websites) and b) also more advanced and thus work around poor UA sniffing. After all, they're using Firefox.

Is that a better explanation?
(In reply to comment #25)
> (In reply to comment #24)
> > Safari got the point here; their UA says "like Gecko", not "like Firefox".
> > 
> This might be why they have problems on many websites...

Yes, a rendering engine telling a brain-dead sniffing script that it is "like" a completely different rendering engine doesn't have any potential for problems at all. Frankly, I think that's rather irrelevant and not at all the point that Gerv intended. Changing Safari's UA to include "like Firefox" instead of "like Gecko" would probably not, in fact, actually fix many of these problems.

I completely support the motivation behind this bug. I mentioned elsewhere that UA strings have outlived their usefulness and that it's high time someone -- and it's pretty clear that someone isn't going to be Microsoft or Apple -- took the initiative here and said "user-agents don't matter; rendering engines do." The Mozilla community is in the unique position to fix this problem and take a great step toward making the Web a better place. Basically, what Stuart said in comment 23.
(In reply to comment #27)
> UA strings have outlived their usefulness

If that were true, we wouldn't have any problem with any UA change for Firefox 3, including making the string empty.

> and that it's high time someone --
> and it's pretty clear that someone isn't going to be Microsoft or Apple -- took
> the initiative here and said "user-agents don't matter; rendering engines do."

If we do that and lose market share, the only effect will be to help the others who do not agree with your view on user-agent morality.

> The Mozilla community is in the unique position to fix this problem and take a
> great step toward making the Web a better place. Basically, what Stuart said in
> comment 23.

Or lose market share if we fail, and make the Web a worse place. Pick your battles.

Gerv, please get real. You have absolutely no way to assess the "likelihood" of 44 dependent bugs representing all the sites that would break if we removed "Firefox" from the Firefox 3 UA string. Sam points to trends, which are easy to predict, toward higher numbers.

The specific Mozilla manifesto principles do not tell us what to do here. If we do anything, it could backfire. Ideally we would measure twice, cut once. I do not see a way to do that in this instance. I'd rather not take chances. Neither would the Camino owners, apparently.

/be

I’m not planning to jump into the entire UA string discussion.  But I do want to comment on a few of the policy discussions here.  In particular, I disagree fundamentally with the idea that all Gecko browsers should share in the success of one of them, in this case firefox.    I’m for some reason unable to connect to the news server at this point, so am adding the comment here.  Will probably start a thread in governance when I can get access.  

(Note that the discussion below is absolutely NOT about Camino or SeaMonkey, or whether Camino adding Fx to its UA string is good or useful.  It’s about the general statement of assuming all Gecko based browsers – or  should share the benefits of one.  )

Assume someone takes Gecko.  They use Gecko to build a proprietary browser application whose main purpose is to extract as much of people’s personal browsing habits as is possible.  The application does not protect people’s security (a stated Manifesto principle) or their privacy. It may have actual security vulnerabilities, it may have social attacks, it may be intended to track identifiable personal data so the vendor can sell it. 

Why should that Gecko based application be able to share in the success of Firefox, or any other product? They’ll share to the extent that the web is gecko compatible of course.  But beyond that, why should we assume that anything built on Gecko is equally good –either as software, or for users, or for its support of the Manifesto?  

Gecko is open source software.  People can use it for whatever they want.  That reflects a Manifesto value (principle 7).  Assuming that the end results – that each product with Gecko in it – is equal, just because it embeds Gecko, or somehow morally entitled to all various rights, seems a long stretch.  
As the reporter, I would like to clarify that this bug is *not* about "sharing Firefox's success with other Gecko browsers". It is about using Firefox's success to keep the web open to other Gecko browsers--browsers that are currently being unfairly cut out not due to security or privacy concerns, but due to a webmaster's ignorance about sniffing for "Gecko" rather than "Firefox" to determine content compatibility.

Mitchell writes: "They’ll share to the extent that the web is gecko compatible of course." *This* is what the bug is about. This is *not* happening. It's not happening because a lot of sites are sniffing for "Firefox" instead of "Gecko", and thus blocking out Camino and Seamonkey, either from the whole site or merely from some features of it, when they would handle the content equally well.

The proposed solution here is to remove "Firefox" from the UA string so that these sites are forced to do it right. The alternative is to add "Firefox" to the UA string of all other Gecko browsers.

There are some sites that legitimately block non-Firefox Gecko browsers, usually because they have not undergone the same privacy/security review, and this bug (and this discussion) is not about those.
By and large, the Web is not "Gecko-compatible." The Web, where it is not the province of IE (which, admittedly, is much less common than it used to be, thanks in large part to the widespread success of Firefox and Safari), is "Firefox-compatible."

This bug should be -- and is -- about erasing that distinction, or at least blurring it to the point where it is no longer relevant.
(In reply to comment #30)
> The alternative is to add "Firefox" to
> the UA string of all other Gecko browsers.
I think this would be a good solution and rather harmless. As long as Internet Explorer 6 calls itself "Mozilla 4.0" it is not a shame at all to have "Firefox" in your UA string ;). 



> I think this would be a good solution and rather harmless.

This entire discussion exists because this solution is not "harmless". 

1) It's a further bloat of the user agent string for other browsers, bloat which will never get removed (like "Mozilla/5.0", which we can't now change or remove) and which has to be sent on every request.

2) It moves the focus away from rendering engines and on to browser names.

This last point could come back and really bite some day. Imagine what trouble we would have had in the early days of what is now Firefox if some sites had sniffed for Phoenix, then others for Firebird, instead of Gecko. Are we so convinced that our flagship product is going to be called "Firefox" forever? Would we have said the same thing about the name "Mozilla" 5 years ago?

IMO, it is in the best interests of the project - including those bits of it currently focussed on Firefox - for the web to be "Gecko compatible" rather than "Firefox compatible". And I think there's a strong argument that doing what's recommended in this bug needs to happen to get us there. If the right thing is made to be the same as the easy thing, people will do the right thing.

Gerv

(In reply to comment #32)
> (In reply to comment #30)
> > The alternative is to add "Firefox" to
> > the UA string of all other Gecko browsers.
> I think this would be a good solution and rather harmless.

Well, it means that you can't simply check for "Firefox" in those scenarios:

(comment #15)
> There are
> plenty of legitimate reasons for knowing what browser you're using, not just
> what Gecko you're using.  Not necessarily for random content, but for a site
> offering an extension for Firefox 2.0, they'd want to show alternate content
> for Camino or Seamonkey or Epiphany.

Same for statistics: To identify Firefox, you'll have to verify that it's not Camino or SeaMonkey or Epiphany or SomeOtherGeckoBrowser first.
So how is that better than having them look for Gecko and verify that it's Mozilla's main browser (Firefox right now, but could be another name as Gerv points out) rather than one with an explicit browser name (Camino et al)?
(In reply to comment #34)
> Same for statistics: To identify Firefox, you'll have to verify that it's not
> Camino or SeaMonkey or Epiphany or SomeOtherGeckoBrowser first.

There are very few reasons why this would be useful. Statistics are vastly overrated, and are abused more than they are used properly.

That being said, this bug has been WONTFIXed, so there are vastly more appropriate places to continue this discussion, like the newsgroups.
Flags: blocking-firefox3?
You need to log in before you can comment on or make changes to this bug.