Closed Bug 386113 Opened 18 years ago Closed 16 years ago

Put reference to Firefox in User Agent (ua) string

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: csthomas, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

patch
1.85 KB, patch
neil
: superreview-
Details | Diff | Splinter Review 
See bug 384721 and bug 385999.  We should make sure that using SeaMonkey does not artificially produce a worse experience than using Firefox or any other Gecko browser for the sake of hopeless idealism - with our market share, we're unlikely to convince people to ensure widespread sniffing for "Gecko" rather than "Firefox", and I don't get the impression Tech Evangelism is particularly effective.
I'm strictly against putting any "Firefox" reference (or other such sucky stuff) into our UA string.
To clarify that, I'm against doing it by default, our UA is already messy enough without this, see the link in comment #1 - I'd support doing this on known-to-be-bad sites only, along with an appropriate warning, like pointed out in http://home.kairo.at/blog/2007-06/a_possible_idea_for_user_agents
Attached patch patch — — Splinter Review 
This is basically a port of the Camino patch.  I know in Europe alternative browsers are more popular, but here they're not, and it sucks.

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/0000000000 SeaMonkey/2.0a1pre (like Firefox/3.0a6pre)
Assignee: general → cst
Status: NEW → ASSIGNED
Attachment #270254 - Flags: superreview?
Attachment #270254 - Flags: review?
Comment on attachment 270254 [details] [diff] [review]
patch

Need to figure out who I'm going to request reviews from before setting the flags.
Attachment #270254 - Flags: superreview?
Attachment #270254 - Flags: review?
I too think this is a bad idea. If you're going to add (like Firefox), you might just as well add (like IE) (like *) and be done with it.

If you really want this, why not use the User Agent extension? That way we can keep the basic browser clean and prompt proper use of the UA, but you can still browser sites how you want.
(In reply to comment #6)
> If you really want this, why not use the User Agent extension?

Because I want it to work out of the box.  I don't want to have to tell people to get an extension to avoid having a worse experience with SeaMonkey than with Firefox.
So Netscape, Mozilla Suite, Firefox and SeaMonkey have always been based significantly on meeting standards, and by extending the user agent, we're going to start to say that standards no longer matter?

To me, identifying against Gecko should be the standard, not Firefox.

Are we going to have to start implementing all of Internet Explorer's "in-correctness" so we can display pages that are just designed for IE? (admittedly I'm a little out of touch with how much IE allows things to be not to standard).
(In reply to comment #8)
> To me, identifying against Gecko should be the standard, not Firefox.

"should be" is the ideal. Unfortunately, that ideal isn't getting met. Are you going to hire TE resources?

> Are we going to have to start implementing all of Internet Explorer's
> "in-correctness" so we can display pages that are just designed for IE?
> (admittedly I'm a little out of touch with how much IE allows things to be not
> to standard).

We already have implemented the more popular compatibility. Adding this change would create a better user experience for SeaMonkey users at the cost of ideals. If you feel that cost is too high, then that's your decision. The Camino team has decided that user experience is more important.

Everything you're arguing has already been discussed. Please see the "Camino User-Agent String" thread in m.d.t.layout as well as the comments in bug 385999 and bug 384721.
(In reply to comment #6)
> I too think this is a bad idea. If you're going to add (like Firefox), you
> might just as well add (like IE) (like *) and be done with it.

I disagree. Putting Firefox in the UA string will cause many sites to suddenly work (see bug 334967). To show that you might just as well also add MSIE or anything else to the user agent string, you will need to show that many sites (including Alexa top 100 sites) would suddenly work. Unless someone can provide some evidence to this effect, I think that slippery slope is imaginary.

> If you really want this, why not use the User Agent extension? That way we can
> keep the basic browser clean and prompt proper use of the UA, but you can
> still browser sites how you want.

I just tried installing User Agent Switcher, but it doesn't work with SeaMonkey nightlies, which I'm using. Anyway, SeaMonkey should work for popular sites "as is" without needing to install an extension or go into about:config and modifying a preference. If that means SeaMonkey must ship with Firefox in the UA string, I'm all for it.
(In reply to comment #8)
> So Netscape, Mozilla Suite, Firefox and SeaMonkey have always been based
> significantly on meeting standards, and by extending the user agent, we're
> going to start to say that standards no longer matter?

Extending the user agent does not mean that standards no longer matter. Gecko has a long history of adding proprietary IE features, even going so far as to break compatibility with web standards, to get Gecko to work with popular sites. Examples include document.all support, marquee tag support, and MIME type sniffing for Content-Type text/plain. I don't see how SeaMonkey adding something extra to the UA string would even be breaking the standards, much less implementing a non-standard feature allowed by the standards. SeaMonkey would simply be mimicking Firefox as a pragmatic way to get popular sites to work. Mozilla has a long tradition of such pragmatism, so there is plenty of precedent for this decision. It's certainly not suddenly saying that standards no longer matter. That's a strawman argument.
(In reply to comment #3)
> I'd support doing this on known-to-be-bad sites only,
> along with an appropriate warning

As long as the list of sites can be kept up-to-date, this could work. But why bother all users with a warning the majority of them won't even understand? Why not simply add (like Firefox/XXXX) to the end of the UA string? We could still evangelize sites with the Gecko is Gecko campaign <http://geckoisgecko.org/> because we would have a list of the sites. We could also help check that browser stat programs still identify SeaMonkey properly even with Firefox in the UA string. What specifically can be gained by alerting all users to the ruse?
(In reply to comment #9)
> Everything you're arguing has already been discussed. Please see the "Camino
> User-Agent String" thread in m.d.t.layout as well as the comments in bug 385999
> and bug 384721.

Considering what this affects, I'm surprised by the small size of discussion on bug 384721 and the newsgroup. It seemed very "we're going to do this" - full stop. There didn't seem to be any discussion with Mozilla Fo/Co about helping with Tech Evangelism, or on other ways this could be improved. From a quick read there also seemed to be points left unanswered as well.

(In reply to comment #11)
> Extending the user agent does not mean that standards no longer matter. Gecko
> has a long history of adding proprietary IE features, even going so far as to
> break compatibility with web standards, to get Gecko to work with popular
> sites. Examples include document.all support, marquee tag support, and MIME
> type sniffing for Content-Type text/plain. I don't see how SeaMonkey adding
> something extra to the UA string would even be breaking the standards, much
> less implementing a non-standard feature allowed by the standards. SeaMonkey
> would simply be mimicking Firefox as a pragmatic way to get popular sites to
> work. Mozilla has a long tradition of such pragmatism, so there is plenty of
> precedent for this decision. It's certainly not suddenly saying that standards
> no longer matter. That's a strawman argument.

Ok, so it's not necessarily breaking standards, but an additional thought is which sites is this designed to 'fix':

1) Sites which misuse ua detection
2) Sites which do ua detection because that's all their owners want them to run with.

With 1 this will probably work. 2 won't - e.g. Natwest I believe (I know one of the banks does) explicitly tests on specific browsers, it'll work for a short time, but then they will become wise and detect the "like". So our users will then be upset again and we'll have gone backwards in that case.

This is why, IMHO, we should be aiming to use peer pressure to our advantage in BOTH instances. If we add (like Firefox/XXXX), then the gecko is gecko campaign  is worthless and will just be laughed at if it continues - and we may as well just say we're like anything.
(In reply to comment #13)
> This is why, IMHO, we should be aiming to use peer pressure to our advantage in
> BOTH instances. If we add (like Firefox/XXXX), then the gecko is gecko campaign
>  is worthless and will just be laughed at if it continues - and we may as well
> just say we're like anything.

If you have a form of peer pressure that works, by all means, please propose it in the newsgroups. The Gecko is Gecko "campaign" was created by a Camino user and is nothing more than a one-page website. It was created so that we would have a page to send users to when we closed their bugs and to have somewhere they could point web developers. I'd hardly call that a "campaign" of any sort. If you'd like to laugh, feel free.
(In reply to comment #13)
> With 1 this will probably work. 2 won't - e.g. Natwest I believe (I know one
> of the banks does) explicitly tests on specific browsers, it'll work for a
> short time, but then they will become wise and detect the "like". So our
> users will then be upset again and we'll have gone backwards in that case.

If we know a site wants to block specific browsers, we can simply not add their site to the list. Checking to see whether the site works in Camino can help determine these sites. If the site does not work in Camino with "like Firefox" in the UA string, don't add "like Firefox" to the SeaMonkey UA string for the site. If the strategy fails for some sites, at least we tried. Users can't reasonably fault us for trying our best to get their sites to work in SeaMonkey. There will always be unreasonable users getting upset about something or other, so we shouldn't worry about possibly upsetting them.

> This is why, IMHO, we should be aiming to use peer pressure to our advantage
> in BOTH instances. If we add (like Firefox/XXXX), then the gecko is gecko
> campaign is worthless and will just be laughed at if it continues - and we
> may as well just say we're like anything.

We should still try the Gecko is Gecko campaign. If it doesn't work, it has been empirically shown to be worthless anyway. In that case, we can be pragmatic about the issue and add "like Firefox" to the UA string.
> 2 won't - e.g. Natwest I believe (I know one of
> the banks does) explicitly tests on specific browsers, it'll work for a short
> time, but then they will become wise and detect the "like". So our users will
> then be upset again and we'll have gone backwards in that case.

Since we still include "SeaMonkey" as well as "like", people who explicitly want to block non-Firefox Geckos are still free to do so.  This is to address the teeming masses of idiots (Microsoft, ABC, Nintendo, Vongo, etc) who don't recognize SeaMonkey out of mere ignorance, not the security-minded folks who only support browsers they've determined meet their requirements.  If Mo[CF]o aren't going to put resources into Tech Evagnelism, we don't have much of a chance of getting widespread support - how many millions of users did Firefox have before the web started becoming more non-IE-friendly?
Flags: in-testsuite-
I don't think that adding "like Firefox" or anything "like that" will have any positive effects in the mid or long term, thus I am strictly against it.

IE is using "Mozilla/4.0", Safari is using "like Gecko" - to the effect that checking for these strings is quite ineffective and those "website programmers" will start to look for other ways of identifying the client. Stuffing UA strings with yet another compatibility claim is definitely no useful solution.
> IE is using "Mozilla/4.0", Safari is using "like Gecko" - to the effect that
> checking for these strings is quite ineffective and those "website programmers"
> will start to look for other ways of identifying the client.

Not if their check for "Firefox/" is out of mere ignorance, as it is in every case I've seen (since my banks don't block SeaMonkey).
(In reply to comment #17)
> IE is using "Mozilla/4.0", Safari is using "like Gecko" - to the effect that
> checking for these strings is quite ineffective and those "website programmers"
> will start to look for other ways of identifying the client. Stuffing UA
> strings with yet another compatibility claim is definitely no useful solution.

It's clear to me that many sites are simply checking for "Firefox" instead of "Gecko" in the UA string. Adding "like Firefox" to the UA string of Camino and SeaMonkey and other Gecko browsers will therefore help those browsers work on many more sites. Sure, some sites really do want to check for Firefox, and they will quickly learn to look for the "like" or some other giveaway in Camino and SeaMonkey. But in the long run, most sites will keep simply checking for "Firefox" and will keep working in Camino and SeaMonkey. It seems like a perfectly pragmatic and useful solution to the problem to me.
> But in the long run, most sites will keep simply checking for "Firefox"

I don't own a crystal ball, but it says that you don't either. :-P

Putting claims into the UA just stinks - it started with IE saying Mozilla/4.0 (although they can refer to Mosaic, too), it continued with Safari ("like Gecko"), and I really do hope it just dies there. 
To no surprise, such behaviour will get sued in no time in the business world! 

Polluting the UA will be a short-lived "success" at best, but instead damage both our reputation and even the MoFo mission - you don't further choice by claiming to be "like"...

> and will keep working in Camino and SeaMonkey.

Camino is even more "nichy" than SeaMonkey, so you probably need every argument you get. ;-)

> It seems like a perfectly pragmatic and useful solution to the problem to me.

Pragmatic: yes. Useful: no. 


If we want sites to check for "Gecko" instead of "Firefox" in their UA strings, the mass of UAs _without_ "Firefox" but with "Gecko" in their UA strings must be high enough. If every Gecko-based browser adds "Firefox" to its UA, we will more or less be telling them "checking for Firefox is a good idea".

The only solution I know of that helps both evangelizing and users getting into websites is what I described in my blog and linked in comment #3.

That said, you basically have the choice of adding "like Firefox" to the default UA string or having me as a contributor, I can't imagine having both at the same time, as I would not be able to identify myself with an even crappier UA string than the current one.

IMHO, the effort spent on thinking about this non-solution would be much better spent with developing a dynamical per-site spoofing solution with evangelizing helpers in a similar way to what I described in my blog.

Do we have:
$(topsrcdir)/browser/config/version.txt

on a clean SM checkout?


(In reply to comment #22)
> Do we have:
> $(topsrcdir)/browser/config/version.txt
> 
> on a clean SM checkout?

Yup.
Comment on attachment 270254 [details] [diff] [review]
patch

Quick & simple way to make SM work as well as Firefox for users, without requiring them to hack prefs / get extensions, and without expecting people who just want to get work done to contact webmasters or sign up for & learn to use bugzilla so they can file TechE bugs.
Attachment #270254 - Flags: superreview?(neil)
Attachment #270254 - Flags: review?(neil)
Comment on attachment 270254 [details] [diff] [review]
patch

>+#expand pref("general.useragent.extra.zznotfox", "(like Firefox/__FOX_APP_VERSION__)" );
Sorry, I don't like the idea of a change that users can't easily override.
Attachment #270254 - Flags: superreview?(neil)
Attachment #270254 - Flags: superreview-
Attachment #270254 - Flags: review?(neil)
I know it would be disruptive in the short term, but can't we just get all the browser vendors together and get sensible UA strings.

Gecko/2.0 (Mac OS X) Gecko/123456789
WebKit/1.0 (WinXP) Safari/3.0
IE/8.0 (WinXP)
Opera/9.0 (Linux)

Sorry, I'm being far too idealistic here.
(In reply to comment #26)
> I know it would be disruptive in the short term, but can't we just get all the
> browser vendors together and get sensible UA strings.
> 
> Gecko/2.0 (Mac OS X) Gecko/123456789
> WebKit/1.0 (WinXP) Safari/3.0
> IE/8.0 (WinXP)
> Opera/9.0 (Linux)
> 
> Sorry, I'm being far too idealistic here.
> 

The Mozilla Corporation already refused to remove Firefox from the user agent.  You could try evangelizing them...
FWIW, I think that adding "(like Firefox)" by default to the UA string really, really sucks. The fight should be to promote standards awareness, not the contrary. And the standard is Gecko, not Firefox.

As a compromise solution, I would propose an option to add "(like Firefox)" to the UA string (Advanced -> HTTP Networking?). If you really want to be pragmatic, set this option on by default (although I think it should be off), but, at the very least, users should know that pretending to be Firefox is a BAD idea and used as a last resource.

I am against this change. Really. But if it comes it must be *completely* user configurable (GUI not only hidden prefs).

(In reply to comment #21)
> ... developing a dynamical per-site spoofing solution with evangelizing
> helpers in a similar way to what I described in my blog.

see Bug 387416 and links

Chris, are you still working on this ?
Severity: normal → enhancement
Depends on: 384721
Version: 1.8 Branch → Trunk
Removing bogus dependency on bug 384721; what SeaMonkey chooses to do or not do is completely orthogonal to Camino's UA.
No longer depends on: 384721
I'd consider this WONTFIX for myself, but not marking as such atm due to the flamewar-capacity of this topic.
I do consider this WONTFIX, too.
I believe this feature (if desired) is extension fodder. There are already some extensions that do at least part of the job; and the rare times when I need to check whether a site discriminates between Firefox and SeaMonkey by their user-agents, I create a string pref in Sm with the name general.useragent.extra.firesomething and some name like "NOT Firefox/3.0". (And I "Reset" it once it's not needed anymore.)
The question is of course if one consider this should be handled by users or not. If a site doesn't work, am I supposed to install an extension or fiddle with the ua?
(In reply to comment #35)
> The question is of course if one consider this should be handled by users or
> not. If a site doesn't work, am I supposed to install an extension or fiddle
> with the ua?
> 

If a site works only for browsers whose UA includes "Firefox", you can change yours either through about:config or via an extension (at your choice); and in addition you should if possible report the site in a bug on the "Tech Evangelism" component (isn't that what "Help -> Report Broken Web site" is for?). In this "Firefox vs. other Gecko" case, your new bug should also be declared as "blocking" bug 334967 if you know about the latter.
(In reply to comment #36)
> (In reply to comment #35)
> > The question is of course if one consider this should be handled by users or
> > not. If a site doesn't work, am I supposed to install an extension or fiddle
> > with the ua?
> > 
> 
> If a site works only for browsers whose UA includes "Firefox", you can change
> yours either through about:config or via an extension (at your choice); and in

Neither of which is an option for most users, as most users have absolutely no idea what a user-agent string even *is*, much less how to go about changing it. They just know the site doesn't work.

> isn't that what "Help -> Report Broken Web site" is for?

Where do those reports go? Who triages them? Do those individuals file TE bugs on behalf of the reports where appropriate?

). In this "Firefox vs. other Gecko" case, your new bug should also be
> declared as "blocking" bug 334967 if you know about the latter.

Which, again, most users won't.
(In reply to comment #36)
> (In reply to comment #35)
> > The question is of course if one consider this should be handled by users or
> > not. If a site doesn't work, am I supposed to install an extension or fiddle
> > with the ua?
> > 
> 
> If a site works only for browsers whose UA includes "Firefox", you can change
> yours either through about:config or via an extension (at your choice); and in
> addition you should if possible report the site in a bug on the "Tech
> Evangelism" component (isn't that what "Help -> Report Broken Web site" is
> for?). In this "Firefox vs. other Gecko" case, your new bug should also be
> declared as "blocking" bug 334967 if you know about the latter.
> 

Yes, I know. But is that what you tell your friends/family etc? Does your grandma do this?
(In reply to comment #38)
[...]
> Yes, I know. But is that what you tell your friends/family etc? Does your
> grandma do this?
> 

Actually, I wouldn't recommend SeaMonkey to my, well, my 83-year-old mother even if she knew how to use a browser, because Sm 1.1 isn't "good enough" IMHO, and Sm2 hasn't yet reached "public release" status; but if she had that problem, I would change her about:config myself.

My 84-year-old (divorced) father is much more computer-literate than my mother is, and so are my sisters, brothers, and nephews. Yes, I would tell this to them without hesitation, and take the time to explain if they didn't immediately understand.
I would prefer them using the mechanism bug 387416 is for - unfortunately nobody has even started to work on this yet, despite me pledging a thousand US dollars for it.
(In reply to comment #40)
> I would prefer them using the mechanism bug 387416 is for - unfortunately
> nobody has even started to work on this yet, despite me pledging a thousand US
> dollars for it.
> 

Well, actually, so would I. Maybe I should tell them (if they run into this bug) to use Konqueror, which includes such a "dymamic UA spoofing mechanism" (with a pre-populated, user-changeable, "spoofing list"). Or at least to use it for those "badly behaving" sites.
(In reply to comment #39)
> (In reply to comment #38)
> [...]
> > Yes, I know. But is that what you tell your friends/family etc? Does your
> > grandma do this?
> > 
> 
> Actually, I wouldn't recommend SeaMonkey to my, well, my 83-year-old mother
> even if she knew how to use a browser, because Sm 1.1 isn't "good enough" IMHO,
> and Sm2 hasn't yet reached "public release" status; but if she had that
> problem, I would change her about:config myself.
> 
> My 84-year-old (divorced) father is much more computer-literate than my mother
> is, and so are my sisters, brothers, and nephews. Yes, I would tell this to
> them without hesitation, and take the time to explain if they didn't
> immediately understand.
> 

My point was that I don't think users should be forced to bother with this.

(In reply to comment #42)
[...]
> My point was that I don't think users should be forced to bother with this.
> 

Well, as KaiRo reminded us in comment #40, solving bug 387416 would be a better solution, which in most cases wouldn't either "force" users to bother with this.
(In reply to comment #30)
> Chris, are you still working on this ?

No.  Apparently practical, easy solutions aren't what we're looking for, so I'm not wasting more time on this.

(In reply to comment #34)
> I believe this feature (if desired) is extension fodder.

The whole point is that "normal people" who are suckered into using SeaMonkey by a geek acquaintance shouldn't have a bad experience.
Assignee: cst → general
Status: ASSIGNED → NEW
Default UA it (mostly) the result of a number of default prefereces. Moving to Sm::Prefs
Assignee: general → nobody
Component: General → Preferences
QA Contact: general → prefs
We still have no intentions of fixing this, let's mark it so officially.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: