Closed Bug 591617 Opened 14 years ago Closed 14 years ago

Kill .compatMode UA pref and always append "Firefox/x.y" for non-Firefox apps

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kairo, Unassigned)

References

Details

Bug 581008 introduced a general.useragent.compatMode.firefox pref that can be set by anyone to append a "Firefox/x.y" token to the UA easily. Given that bug 588874 changed all Firefox-pre-versions, including nightlies, to send a "Firefox/x.y" token anyhow, I guess we pretty much have given up on any Tech Evang on websites sniffing for "Firefox" in the UA, so it's better to just hardwire any app that isn't named "Firefox" by itself to append a "Firefox/x.y" token right away and kill the pref, as it's becoming more and more ludicrous for anyone using Gecko not to send a Firefox token anyhow.
Can we hardwire "WebKit/1.0", too, just in case?
> I guess we pretty much have given up on any > Tech Evang on websites sniffing for "Firefox" FWIW, the reason was not "we give up on tech Evang", but "We want the test builds to be closer to release builds, in this case, to catch problems earlier". You may argue "same effect", but the reason is different. Given that I agree that sites should not check for "Firefox", and I think we should continue the tech evang in order to limit the UA string lengthening nonsense, I would like this pref to stay, and default to false for any non-Firefox apps.
(In reply to comment #2) > > I guess we pretty much have given up on any > > Tech Evang on websites sniffing for "Firefox" > > FWIW, the reason was not "we give up on tech Evang", but "We want the test > builds to be closer to release builds, in this case, to catch problems > earlier". You may argue "same effect", but the reason is different. For one, it doesn't matter, for the other, the argument is bogus, as the UA is nothing that catches problems earlier or later. > Given that I agree that sites should not check for "Firefox", and I think we > should continue the tech evang in order to limit the UA string lengthening > nonsense, I would like this pref to stay, and default to false for any > non-Firefox apps. Any app based on Geck 2 or later not setting this pref in releases is probably ludicrous anyhow, as much as I hate saying that, it's completely true, and one reason for SeaMonkey being seen as crap by a number of users is that we don't set "Firefox/x.y" in the UA right now.
Why Gecko 2? What changed? I don't think the sniffers changed for Firefox 4, did they? > one reason for SeaMonkey being seen as crap by a number of users is that > we don't set "Firefox/x.y" in the UA right now. I run with "Gecko/2.0 (Linux)" as UA string since a while, and haven't noticed many problems, only on two FAQ sites IIRC. Can you please file specific (TechEvang) bugs about sites breaking when there's no "Firefox" in the UA string, and reference them here? I'll do that about the one site I know.
(In reply to comment #4) > Can you please file specific > (TechEvang) bugs about sites breaking when there's no "Firefox" in the UA > string, and reference them here? bug 334967 has an extensive list (and there are many more out there)
(In reply to comment #0) > Given that bug 588874 changed all Firefox-pre-versions, including nightlies, to > send a "Firefox/x.y" token anyhow, I guess we pretty much have given up on any > Tech Evang on websites sniffing for "Firefox" in the UA, so it's better to just > hardwire any app that isn't named "Firefox" by itself to append a "Firefox/x.y" > token right away and kill the pref, as it's becoming more and more ludicrous > for anyone using Gecko not to send a Firefox token anyhow. I sense some frustration here, so I want to explain: the switch from Minefield to Firefox was not at all done because we're giving up on evang, it was because we want nightlies to behave as releases. The addition of the compatMode pref was not done because we want other products to use it, it was because we removed any other way that people could advertise as two apps at once, and the existing usage of that capability was to advertise as Firefox. I'm not suggesting SeaMonkey use it, and I'd love to live in a world where you don't, but that decision is totally up to you... I think it's worthwhile evangelizing sites who make this mistake, and I'd hope we help you in that effort. Promoting Gecko for other apps is very, very important, and this squarely falls under that.
(In reply to comment #4) > Why Gecko 2? What changed? Bug 588874 did. Please read my comment #0. > Can you please file specific > (TechEvang) bugs about sites breaking when there's no "Firefox" in the UA > string, and reference them here? I'll do that about the one site I know. EVERYTHING basing its work on .NET classes, any bing map with overlays, but I am tired of filing bugs as nobody cares anyhow, esp. Mine..., er, Firefox testers, devs, and users.
(In reply to comment #7) > I sense some frustration here, so I want to explain: the switch from Minefield > to Firefox was not at all done because we're giving up on evang, it was because > we want nightlies to behave as releases. That might have been the reason, but not the outcome. > I'm not suggesting SeaMonkey use it Then you suggest SeaMonkey to dies silently, without even knowing that you do. Really. Live out here in the jungle and then still think differently.
> > Why Gecko 2? What changed? > Bug 588874 did [Minefield now says "Firefox"] That's not what I meant. This doesn't change the web. Just because Minefield now says "Firefox" doesn't mean that more websites break when "Firefox" is not there. Apparently, Seamonkey and Camino could so far live without "Firefox" in the UA string. What changed *on the web* that you now think this is no longer feasible? > I am tired of filing bugs That's fine. But that doesn't mean that Camino or Beonex should be forced to use "Firefox" in the UA string. > Live out here in the jungle I do, as I said - "Gecko/2.0 (Linux)". I'm fine.
(In reply to comment #10) > > > Why Gecko 2? What changed? > > > Bug 588874 did [Minefield now says "Firefox"] > > That's not what I meant. This doesn't change the web. It does, because it makes Minefield testers stop to care if bad spoofing is used or not. And Minefield testers are probably more than all other Gecko-browser users counted together. > Apparently, Seamonkey and Camino could so far live without "Firefox" in the UA > string. No, they couldn't. Camino has been switching include Firefox/ a long time ago, and I opposed it heavily back then, but since then I have given up, seeing how much SeaMonkey is harmed by not making that decision. We have lost more users for that than we got to write even one message to their beloved broken websites. > > I am tired of filing bugs > > That's fine. But that doesn't mean that Camino or Beonex should be forced to > use "Firefox" in the UA string. I think it should mean just that. Gecko is broken for many major sites nowadays without sending "Firefox/x.y" and we shouldn't ship broken Mozilla software, and IMHO shouldn't even allow others to do so. > > Live out here in the jungle > > I do, as I said - "Gecko/2.0 (Linux)". I'm fine. Continue living in your dream world, but do it with overrides, while we address the real world. I have given up on the dream and decided to go with reality and some alcohol. In the end that's more human than your utopia.
Please, no insults. So: Because you changed your mind, everybody else should be forced, too. Clear. Suggesting WONTFIX. I still don't want "Firefox" in my products.
(In reply to comment #12) > So: Because you changed your mind, everybody else should be forced, too. Clear. No, because reality needs it. > Suggesting WONTFIX. I still don't want "Firefox" in my products. Your problem.
(In reply to comment #13) > > Suggesting WONTFIX. I still don't want "Firefox" in my products. > > Your problem. There's no good reason to create this problem in the first place, though. What this bug suggests would be pointless for Gecko-based applications which don't need access to the whole web. Gecko-based browsers are free to flip the pref -- this is really their decision.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
(In reply to comment #12) > Suggesting WONTFIX. I still don't want "Firefox" in my products. Me too. My XulRunner application is not a Firefox. (In reply to comment #13) > No, because reality needs it. Reality does not need. If reality assumes my App being a FF because of UA string lying reality may provide stuff not working with my App. I.e. Reality might assume installing plugins being possible, but my Application does not implement this. Reality might assume Java being available or might be switched on, but my application does not implement switching Java on. There are many more samples of stuff SM and FF implement but my application does not, because it does not need it. My application can surf in the web, but this is not focus of that app; it is just possible to go to the support pages and read bugzilla and MDC etc. from within the application, but it is not intended for surfing all over the web. Providing FF addons etc to my app mostly does not work, so Firefox must not be part of the UA string, where no Firefox is, except the user wants enables it via pref, which must be default disabled.
(In reply to comment #14) > There's no good reason to create this problem in the first place, though. IMHO, there is, unless we don't send a UA at all in the first place (not sending the brand of the product at all might sound like another good choice, but defies the purposes of the UA at all, so better not to send one in the first place, then). (In reply to comment #15) > Reality does not need. Then you are living in a different reality and are not using mainstream websites of e.g. American providers like live.com et al. I still heavily disagree with WONTFIXing this, but then, we know we suck and if we want to continue to, who am I to dispute it.
Idea: Convert compatMode pref to a build-time configure option?
(In reply to comment #17) > Idea: Convert compatMode pref to a build-time configure option? That's a bad idea, as any browser really needs in in the web of 2011 onwards, and as XULRunner isn't a browser, it would need to disable it, which in turn means that you can't build a decent browser on this XULRunner any more. Either a pref that is hard to turn off or an automatic system to always have the Firefox token in, anything else is probably worse than both. And let me tell everyone who has been affronting me in here that I hate this situation as much as you do, but I'm reading enough messages of people coming to SeaMonkey support for the browser not working with some rather large websites they're using, some of which are turning away from SeaMonkey for that, and I see all those cases leading back to bad sniffing, so I see a lot more of the realities out there than you do in your personal browsing experience. And what I'm seeing is not through the most naive-consumer-friendly channels, so it's probably just a very small tip of the iceberg - as unfortunate as this whole story is. :(
(In reply to comment #18) > (In reply to comment #17) > > Idea: Convert compatMode pref to a build-time configure option? > > That's a bad idea [...] I was sort of implying application build time, not necessarily XULRunner itself, but I wasn't really specific. Fair enough. Clarification, then: Convert compatMode pref to an option in application.ini or similar?
As to this SeaMonkey argument, I don't personally have a monkey in this fight, but the perspective of many is that anything "Gecko based" is effectively "Firefox based". It may not be technically true, but UA sniffers are not technical people, hence the problems. Whatever anyone's opinions on the matter, the temperature of this bug is a bit higher than it needs to be...
(In reply to comment #19) > Convert compatMode pref to an option in application.ini or similar? Might be reasonable, though in that case, I'd make it an optional one that defaults to on. (In reply to comment #20) > It may not be technically true, but UA sniffers are not > technical people, hence the problems. It's true in perspective of the vast majority of development, marketing, usage and whatever else is out there, even though it's not really true in the strict sense (that's not an attack, just a reality check, and there are good reasons for things being this way, which we don't need to discuss here). And given that, it's just natural that web developers must be ignorant of anything Gecko besides Firefox. Actually, due to the web dev community being very technically skewed, we even have an oversized proportion of people there who know those things - still a minority though, and we won't be able to change that. Some even think they don't "support" anything besides MSIE and Firefox with good reasons - think testing effort, etc. Basically the same arguments we make when we unsupport old operating systems. Still, that all goes off-topic here.
I lost track of this bug a bit, I admit, but I have a question (as someone whose UA string basically never contained "Firefox" until dwitte's recent patch): doesn't SeaMonkey have like 5x the number of users as FF nightlies? It doesn't seem to me that Firefox nightlies having "Firefox" in the UA string is going to change that balance very much. I asked in another bug about the recent (last 2 years?) history of sniffing issues being found due to "Minefield" use, and resulting in site owners changing to more general Gecko sniffing. Does anyone who is railing against the loss of 40K "Minefield"-UA daily users have that information to support the amount of emotional energy being expended over reducing the Gecko-but-not-Firefox-UA population by < 20%?
(In reply to comment #22) > doesn't SeaMonkey have like 5x the number of users as FF nightlies? Our total user base - at least the part we can measure, i.e. everyone on supported versions (2.x, first of which was released 10 months ago) is slightly under 100k ADU. I can't find any source that telly me anything about Minefield ADU, so I can't compare, but I become jealous every time you guys talk about abandoning some OS version, as usually you're abandoning more users with such things than we have in total. > the loss of 40K "Minefield"-UA daily users If that's the ADU number you have then it's equivalent of a third to half of our total users, most of which don't even come as far as having the idea of changing a UA, while Minefield (nightly in general) testers are already skewed to be much more aware of such things like Tech Evang. In fact, losing Minefield users in Tech evang probably means that the whole TE community will be 5 people if guessed optimistically (pessimistically it's 1-2).
(In reply to comment #16) > IMHO, there is, unless we don't send a UA at all in the first place (not > sending the brand of the product at all might sound like another good choice, > but defies the purposes of the UA at all, so better not to send one in the > first place, then). I hate the web site sniffing "Firefox", we should have changed our UA string to Mozilla/5.0 (Windows NT 6.0; rv:2.0b6pre) Gecko/20100901 dont sniff Firefox/4.0b6pre And later in a future release to just Gecko/20100901
You need to log in before you can comment on or make changes to this bug.