There are various sites that sniff for "Firefox" in our UA string, which means that they'll not work (or work differently) in the upcoming 2.0 alpha 2, as I understand it. We should probably try to evangelize them before we ship that...

I don't see a way to make this block 1.8.1a2.... Doing next-best thing.

I'm adding all the "works in Camino-spoofing-as-Firefox, broken in Camino-id'ing-as-Camino" TE bugs I know of, which are sites that will probably break for Minefield/Bon Echo, too. Bug 330584 doesn't seem to be UA-string related according to the test the reporter performed; it seems it should be UA sniffing, but it's not clear why it's not, so it's not among the additions.

If we want good feedback on site compatibility in upcoming 2.0 and 3.0 alphas and beta's the UA string needs to send Firefox. It shouldn't be that way, but it looks like a growing number of sites are sniffing firefox and not gecko... Putting together, evangelizing, and raising the visibility of an up-to-date sniffing doc on devedge might help... pointing to the doc in alpha and beta release notes might catch the eye of web content developer that we are targeting in alpha and beta's

Frankly, I think that if sites are sniffing for Firefox and not Gecko, that's something that's quite bad from the Mozilla Foundation's point of view. Or ought to be.

I agree with bz. This is actually a good opportunity for us to open up the web for Camino, Minimo, etc. I've started a personal campaign <http://bclary.com/blog/2006/04/21/browser-detection-part-duh-will-they-ever-learn/> to get the news out and to explain why the user agent changes were made. It references the original article I did for DevEdge about browser detection <http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support> which could probably be replaced by a less "tome-like" article. I've also updated my ua sidebar <http://bclary.com/blog/2006/04/22/user-agent-string-sidebar-updated/> to include Minefield and Bonecho. Apart from writing docs for DevMo and linking to them from the release notes, I think giving an interview for the tech press on the ua changes in Bonecho and Minefield and the reasons for the changes would go a lot farther in getting the news out to web developers and their managers and to put the mark of cain on those who have traded their integrity for clicks and caused us so much trouble. /bc

(In reply to comment #3) > Putting together, evangelizing, and raising the visibility of an up-to-date > sniffing doc on devedge might help... I was going to suggest this as well...the docs on browesr detection and sniffing on DevMo are rather dated (and hard to find--you have to be looking for them to find them). I'm not the right person from a technical point-of-view to write something, but I had been drafting something that may be useful in jump-starting a new article: http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko

Adding http://www.yahoo.com/preview to the list. I don't know if it is sniffing for Firefox or not but says only Firefox 1.5 is supported.

(In reply to comment #7) > Adding http://www.yahoo.com/preview to the list. I don't know if it is sniffing > for Firefox or not but says only Firefox 1.5 is supported. Yes, yet another Yahoo! property is doing bad sniffing; I get the "not a supported browser" error in Camino 1.0+ (1.8branch), but when I spoof the UA as Fx 1.5, the site loads. Someone should file a bug on that site and have it block this bug, too...

This seems to be worth continuing evangelism, but I'm not sure what it would mean to have it on the blocking list for a release; therefore minusing blocking1.8.1 nomination.

See comment 1 for why the nomination was there. Are we actually doing any evangelism, btw? Or just hoping it somehow happens?

(In reply to comment #10) > Are we actually doing any evangelism, btw? Or just hoping it somehow happens? Just hoping. I tried to shame MSNBC and Yahoo! to no avail.

Maybe we should rethink the whole UA string. What good is it when used to sniff improperly? IE has been Mozilla 4.0 for over 10 years now. Why not try to make it hard to sniff improperly? Instead of Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.0.7) Gecko/20060915 Firefox/1.5.0.7 make it something like this Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; Gecko rv:1.8.0.7/20060915/1.5.0.7), a browser built upon the renowned highly web standards compliant and secure Gecko rendering engine that is the heart of several open source web browsers, including Camino, Epiphany, Firefox, K-Meleon, Mozilla, Netscape, SeaMonkey and XULRunner. That's essentially built in evangelism, and over 300 characters for the sniffers to digest. When it prints in the browser about window, it can be modified if necessary to make it clear exactly which of the listed browsers is displaying it. If every Gecko variant does the same thing, eventually sniffers will figure out the "right" way to sniff. Alternatively, leave out all names except Gecko, meaning no Mozilla or Firefox either.

I think user-agent strings have outlived their usefulness. Far too many so-called "Web designers" use them at best improperly, and at worst for the purpose of excluding browsers for which no additional support effort is necessary. Browsers have become sophisticated enough that, for the purposes of working around certain browser-specific bugs, or for feeding certain content to certain browsers, a Web app can essentially ask the browser whether it supports a certain tag/object/method. User-agent strings are at best a very rough shortcut to this approach and, as literally thousands of sites have proven that they are incapable of using them properly, I propose that the idea of a user-agent string be abandoned entirely. If a user-agent string is absolutely necessary, transmitting only the Gecko version should be perfectly adequate. OS (platform) information is largely irrelevant, as Gecko supports the same Web feature set across all platforms. Where it does matter, there are other means of getting at the information. Language information can and *should* be obtained by looking at the accept-language header of the HTTP request, not at the browser's user-agent string. Again, I'm not aware of any differences in feature support across languages under the same Gecko version. As Felix pointed out, even IE has been "Mozilla/4.0" for ages, rendering that portion of the UA string completely meaningless. The only thing that needs to be in the UA string going forward is, for example: Gecko rv:1.8.0.7/20060915 That's it. Gecko revision number and build date. Gecko has a large enough market share now that designers who choose to ignore it do so at their own peril. If we take the lead on this by refusing to give Web designers an excuse for lame hacks, they'll have no choice but to improve their methods, to the benefit of all. But a revolution cannot happen without an 800-lb gorilla like Firefox to carry the fight. There is no other Gecko browser with large enough market share that businesspeople cannot simply ignore the customers using that browser. Even combined, all other Gecko-based browser products don't have anywhere near the market share that Firefox does. Yes, I'm aware that this proposal would effectively torpedo traditional Web statistics methods. No more detecting that 50% of visitors to your site are using Firefox, 25% are using Camino, 2% are using Minimo, 10% are using SeaMonkey, 6% are using Epiphany, and 7% are using Netscape. But these statistics have, like UA strings themselves, been used more often than not as an excuse not to "support" -- whatever that means -- certain browsers for no technical reason at all; indeed, for no reason other than the perceived size of the user base. "Oh, Camino accounts for less than 1% of the traffic to my site, so I don't care if I exclude Camino users with my sniffing" is a very prevalent attitude among designers, whether the powers that be are willing to admit it or not. These statistics are also wildly skewed, as people who know better will often spoof their user-agent string in order to work around the end result of such attitudes, thus making the statistical conclusions a self-fulfilling prophecy and forever condemning niche browsers -- and more importantly, the users of niche browsers -- to be second-class Internet citizens. So you'll forgive me if I take the attitude that it's about damn time someone *did* make these sorts of distinctions utterly useless. If a designer needs to know anything more than the percentage breakdown of rendering engines visiting a site, he can do good, old-fashioned real legwork and survey his users. Thoughts?

Added three more blockers for historical purposes; they've been fixed for a while but they were exactly this issue, and I think it's important to document them here.

Is there a bug report regarding the reason for all of this (as implied in Zbarsky's original Description)? If so, what is the number? Should that bug be listed as "Blocks" or "Depends on" this one?

Uh.... Did you miss the "Depends on" list of this bug?

I scanned all 90 bugs on which this one depends. Each one of them reports a specific Web site that is incorrectly sniffing. What I'm looking for is the bug report that addresses what is changing in the Gecko core as cited in your original Description of this bug report. I infer from the Description that "Firefox" will no longer appear in the UA string. Under proper configuration control procedures, such a change should be supported by a bug report. Or have I misread the original Description?

(In reply to comment #17) > I scanned all 90 bugs on which this one depends. Each one of them reports a > specific Web site that is incorrectly sniffing. > > What I'm looking for is the bug report that addresses what is changing in the > Gecko core as cited in your original Description of this bug report. I infer > from the Description that "Firefox" will no longer appear in the UA string. It won't appear in the UA string of nightly builds, and any other builds that aren't betas or official releases. > Under proper configuration control procedures, such a change should be > supported by a bug report. Bug 334756.

Someone has proposed at W3C to add a @ua statement to CSS to facilitate user agent sniffing within CSS using conditional statements. The initial proposal is at <http://lists.w3.org/Archives/Public/www-style/2007Oct/0112.html>. Unfortunately, the messages at [W3C home > Mailing lists > Public > www-style@w3.org] are poorly threaded and displayed (e.g., when threads are displayed they are only for messages submitted within a single month). While at least one "Mozilla person" has responded, that was as an individual. Perhaps, the Mozilla organization needs to monitor this proposal and provide OFFICIAL input (possibly attempting to kill it before it goes too far).

Added bug 355623. On reviewing that bug to see if it is still a problem, I realized that it involves incorrect UA sniffing.

What about bug 429924 (IceWeasel not getting Install Link correctly) -- you don't even follow your own rules???

Samuel, this bug is about sites that depend on _Gecko_ features sniffing for "Firefox". Add-ons can depend on more than Gecko: they depend on the exact user interface of the browser. For example, there are Gecko-based browsers (e.g. Epiphany) that don't support AMO-style add-ons at all. Firefox add-ons may well not work in Seamonkey (and vice-versa). I can guarantee you that the "sync on arrival" add-on for Thunderbird doesn't work with Iceweasel. So it shouldn't be offered to Iceweasel. Your bug is asking AMO to know that Iceweasel is nothing like Thunderbird but is somewhat like Firefox. That's a reasonable request, but has nothing to do with rendering-engine sniffing. I hope that clears up the misapprehension under which you seem to be laboring.

Since when is Thunderbird a web browser???

It's pretty simple to create a thunderbird add-on that would allow browsing in an iframe. In any case, the point was that AMO caters to a wide variety of applications, and extensions meant for one of them may well not work on another, even if all the applications involved have the same exact Gecko version. This is a sharp contrast to most website functionality.

Okay, I've mentioned this in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399633 now. Hopefully this will help clear up the iceweasel madness...

Samuel, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting here again. This is most certainly not the place to wage a holy war about whether or not an unofficial version of Firefox is entitled to exactly the same support as an official version of Firefox. (I would argue that Bugzilla in general is not a place to wage such a war, but this bug is DEFINITELY not that place.) In this case, it's pretty clear that robust and intelligent browser sniffing is eminently reasonable to ensure that users of browsers like Camino and Epiphany don't get served content they can't use. If you believe Iceweasel should be treated the same as Firefox by addons.mozilla.org, you should file a bug against addons.mozilla.org and put forth arguments in that bug. Keep in mind that the Powers That Be may, as is their wont, decide that unofficial builds of Firefox will not be entitled to the exact same user experience as official builds, and be prepared to accept whatever decision is reached.

Changed from 492993 being blocked by 334967 to 492993 blocking 334967. That is, 334967 cannot be closed until 492993 is fixed.

(In reply to comment #27) > Changed from 492993 being blocked by 334967 to 492993 blocking 334967. That > is, 334967 cannot be closed until 492993 is fixed. Whoops, sorry about that. That's what I meant to do in the first place. Thanks for fixing it :)

I know a few Swedish sites that sniff for Firefox and warn about my using Minefield or Fennec, including or largest popular bank. Should I add them?

You should file bugs on them and add them to the blocking list here, yes. And of course mail them to complain if you haven't done that yet!

Per Mike Taylor, we're not using this bug to track/prioritize work, and the dependent bugs are already in the tech-evang component, so we're going to close this out.