Closed Bug 334967 (geckoisgecko) Opened 18 years ago Closed 8 years ago

Tracking bug for sites broken by UA string change to not use "Firefox"


(Core Graveyard :: Tracking, defect)

Not set


(Not tracked)



(Reporter: bzbarsky, Assigned: chofmann)




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...
Component: General → Build Config
Product: Firefox → Core
QA Contact: general → build-config
I don't see a way to make this block 1.8.1a2....  Doing next-best thing.
Assignee: nobody → chofmann
Component: Build Config → Tracking
Flags: blocking1.8.1?
QA Contact: build-config → chofmann
Depends on: 306432
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.
Depends on: 321851
Depends on: 295332
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 <> 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 <> which could probably be replaced by a less "tome-like" article. I've also updated my ua sidebar <> 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.

(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:
Depends on: 337056
Adding 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 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...
Depends on: 338499
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.
Flags: blocking1.8.1? → blocking1.8.1-
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.

Depends on: 347509
Depends on: 353435
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: Gecko/20060915 Firefox/

make it something like this

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; Gecko rv:, 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.
Depends on: 379193
Depends on: 357120
Depends on: 131634, 185725
Depends on: 244830, 295252
Depends on: 363175
No longer depends on: 244830
No longer depends on: 287280
No longer depends on: 295252
No longer depends on: 304223
No longer depends on: 321851
No longer depends on: 350315
No longer depends on: 353435
Depends on: 350315
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:

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.

Depends on: 385570
Depends on: 385720
Depends on: 383767
No longer depends on: 385975
Depends on: 386170
Depends on: 386143
Depends on: 373644
Depends on: 354956
Depends on: 283616
Depends on: 386498
Depends on: 321397
Depends on: 291000
Depends on: 308786
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.
Depends on: 306559
Depends on: 386524
Depends on: 386682
Depends on: 315701
Depends on: 385950
Depends on: 386796
Depends on: 389201
Depends on: 389495
Depends on: 390159
OS: Linux → All
Hardware: PC → All
Depends on: 383053
Depends on: 363095
No longer depends on: 383053
Depends on: 391278
Depends on: 392639
Depends on: 393786
Depends on: 394274
Depends on: 394636
Depends on: 395988
Depends on: 396259
Depends on: 397471
Depends on: 397472
Depends on: 397848
Blocks: 399404
No longer blocks: 399404
Depends on: 399404
Depends on: 400320
Depends on: 401583
Depends on: 401709
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 <>.  Unfortunately, the messages at [W3C home >  Mailing lists >  Public >] 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).  
Depends on: 403622
Depends on: 406164
Added bug 355623.  On reviewing that bug to see if it is still a problem, I realized that it involves incorrect UA sniffing.  
Depends on: 355623
Depends on: 409768
Depends on: 410394
Depends on: 410799
Depends on: 411298
Depends on: 411723
Depends on: 413593
Depends on: 417955
Depends on: 419484
Depends on: 419907
Depends on: 417496
Depends on: 403566
Depends on: 420486
No longer depends on: 420486
Depends on: 419129
Depends on: 421014
Depends on: 423362
No longer depends on: 423362
Depends on: 427771
Depends on: lolbug
Depends on: 428361
Depends on: 429116
Depends on: 170023
Depends on: 430149
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 now. Hopefully this will help clear up the iceweasel madness...
Samuel, please read

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, you should file a bug against 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.
Depends on: 430463
No longer depends on: 430463
Depends on: 430436
Depends on: 430020
Depends on: 119134
Depends on: 166261
Depends on: 198953
Depends on: 264594
Depends on: 230914
Depends on: 269434
Depends on: 267752
Depends on: 433464
Depends on: 432759
Depends on: 435253
Depends on: 436222
Depends on: 276282
Depends on: 436528
Depends on: 436530
Depends on: 297917
Depends on: 437066
Depends on: 437842
Depends on: 443690
Depends on: 448341
Depends on: 375482
Depends on: 448754
Alias: geckoisgecko
Depends on: 451075
Depends on: 454828
Depends on: 456222
Depends on: 456480
Depends on: 460662
Depends on: 463826
Depends on: 469281
Depends on: 471184
Depends on: 470759
Depends on: 472843
No longer depends on: 472843
Depends on: 472843
Depends on: 167300
Depends on: 479835
Depends on: 297918
Depends on: 357233
Depends on: 481485
Depends on: 481711
Depends on: 481930
Depends on: 486572
Depends on: 485403
Depends on: 457791
Depends on: 487887
Depends on: 489269
Depends on: 457321
Blocks: 492993
Changed from 492993 being blocked by 334967 to 492993 blocking 334967.  That is, 334967 cannot be closed until 492993 is fixed.
No longer blocks: 492993
Depends on: 492993
(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 :)
Depends on: 493831
Depends on: 497384
Depends on: 501068
Depends on: 503974
Depends on: 504530
Depends on: 505692
Depends on: 508864
Depends on: 511844
Depends on: 513367
Depends on: 522957
Depends on: 523852
Blocks: 527920
No longer blocks: 527920
Depends on: 527920
Depends on: 528127
Depends on: 528496
Depends on: 530359
Depends on: 530786
Depends on: 531331
Depends on: 330094
Depends on: 532574
Depends on: 532595
Depends on: 532831
Depends on: 533490
Depends on: 534096
Depends on: 534550
Depends on: 537054
Depends on: 540201
Depends on: 540446
Depends on: 429200
Depends on: 542560
Depends on: 543684
Depends on: 544687
Depends on: 548303
Depends on: 549527
Blocks: 468835
Depends on: 551673
Depends on: 556316
Depends on: 560510
Depends on: 565675
Depends on: 565859
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!
Depends on: 569279
Depends on: 571755
Depends on: 575392
Depends on: 576936
Depends on: 583934
Depends on: 588046
Depends on: 589584
Depends on: 591622
Depends on: 588529
Depends on: 615814
No longer depends on: 615814
Depends on: 621619
Depends on: 639426
Depends on: 388722
Depends on: 665573
Depends on: 689405
Depends on: 773096
Depends on: 872300
Depends on: 1041111
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.
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.