Last Comment Bug 334967 - (geckoisgecko) Tracking bug for sites broken by UA string change to not use "Firefox"
(geckoisgecko)
: Tracking bug for sites broken by UA string change to not use "Firefox"
Status: RESOLVED INCOMPLETE
:
Product: Core Graveyard
Classification: Graveyard
Component: Tracking (show other bugs)
: Trunk
: All All
: -- normal with 7 votes (vote)
: ---
Assigned To: chris hofmann
: chris hofmann
:
Mentors:
http://wiki.mozilla.org/User:Sardisso...
Depends on: 375482 436222 487887 544687 1041111 119134 131634 165538 166261 167300 170023 185725 198953 230914 264594 267752 269434 276282 283616 287280 291000 295332 297917 297918 304223 306432 306559 307525 308786 315701 318096 318665 319717 319869 321386 321397 325962 327988 328256 328943 329198 330094 330575 330584 332373 334071 334957 337056 338306 338499 339427 339664 344046 347448 347509 348457 349811 350315 354956 355623 357120 357190 357233 357767 358790 359893 363095 363175 367424 slide 370008 373644 376840 377587 378644 379024 379193 380043 383767 384616 385235 385570 385720 385950 385992 386143 386170 386498 386524 386682 386796 387735 388722 389201 389495 390159 391278 392639 393786 394274 394636 395988 396259 397471 397472 397848 399404 400320 401583 401607 401709 403566 403622 403998 406164 409768 410394 410799 411298 411723 413593 417496 417955 419129 419484 419907 lolbug 421014 424002 426112 427771 428361 429116 429200 430020 430149 430436 432759 433464 435253 436528 436530 437842 443690 448341 448754 451075 454828 456222 456480 457321 457791 460662 463826 464074 469281 470759 471184 472843 479835 481485 481711 481930 485403 486572 489269 492993 493831 497384 501068 503974 504530 505692 508864 511844 513367 522957 523852 527920 528127 528496 530359 530786 531331 532574 532595 532831 533490 534096 534550 537054 540201 540446 542560 543684 548303 549527 551673 556316 560510 565675 565859 569279 571755 575392 576936 583934 588046 588529 589584 591622 621619 639426 665573 689405 745191 773096 872300
Blocks: 468835
  Show dependency treegraph
 
Reported: 2006-04-21 09:39 PDT by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2016-07-15 12:13 PDT (History)
41 users (show)
dbaron: blocking1.8.1-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Boris Zbarsky [:bz] (still a bit busy) 2006-04-21 09:39:41 PDT
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...
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2006-04-21 10:40:46 PDT
I don't see a way to make this block 1.8.1a2....  Doing next-best thing.
Comment 2 Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-04-21 19:10:19 PDT
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.
Comment 3 chris hofmann 2006-04-27 17:17:45 PDT
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
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2006-04-27 17:24:39 PDT
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.
Comment 5 Bob Clary [:bc:] 2006-04-27 17:30:27 PDT
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
Comment 6 Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-04-27 19:47:39 PDT
(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
Comment 7 u88484 2006-05-16 04:24:10 PDT
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.
Comment 8 Smokey Ardisson (offline for a while; not following bugs - do not email) 2006-05-16 13:50:36 PDT
(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...
Comment 9 David Baron :dbaron: ⌚️UTC-10 2006-06-13 14:47:12 PDT
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.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2006-06-13 14:50:54 PDT
See comment 1 for why the nomination was there.

Are we actually doing any evangelism, btw?  Or just hoping it somehow happens?
Comment 11 Bob Clary [:bc:] 2006-06-13 14:58:03 PDT
(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.

Comment 12 Felix Miata 2006-10-21 01:43:54 PDT
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.
Comment 13 Chris Lawson (gone) 2007-06-18 13:28:47 PDT
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?
Comment 14 Chris Lawson (gone) 2007-07-02 09:12:14 PDT
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.
Comment 15 David E. Ross 2007-10-31 19:30:19 PDT
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?  
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2007-10-31 21:51:18 PDT
Uh....  Did you miss the "Depends on" list of this bug?
Comment 17 David E. Ross 2007-11-06 17:09:55 PST
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?  
Comment 18 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-11-06 17:23:07 PST
(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.
Comment 19 David E. Ross 2007-11-21 16:06:06 PST
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).  
Comment 20 David E. Ross 2007-12-22 19:32:51 PST
Added bug 355623.  On reviewing that bug to see if it is still a problem, I realized that it involves incorrect UA sniffing.  
Comment 21 Samuel Bronson 2008-04-21 18:36:24 PDT
What about bug 429924 (IceWeasel not getting Install Link correctly) -- you don't even follow your own rules???
Comment 22 Boris Zbarsky [:bz] (still a bit busy) 2008-04-21 19:24:39 PDT
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.
Comment 23 Samuel Bronson 2008-04-21 19:58:39 PDT
Since when is Thunderbird a web browser???
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2008-04-21 20:01:20 PDT
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.
Comment 25 Samuel Bronson 2008-04-21 20:04:58 PDT
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...
Comment 26 Chris Lawson (gone) 2008-04-21 20:10:38 PDT
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.
Comment 27 David E. Ross 2009-05-16 11:40:54 PDT
Changed from 492993 being blocked by 334967 to 492993 blocking 334967.  That is, 334967 cannot be closed until 492993 is fixed.
Comment 28 Chris Lawson (gone) 2009-05-16 11:42:33 PDT
(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 :)
Comment 29 Lars Gunther 2010-05-14 03:07:43 PDT
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?
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2010-05-14 07:43:27 PDT
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!
Comment 31 Benjamin Smedberg [:bsmedberg] 2016-06-28 10:56:06 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.