The Camino team would like to change their user agent string to add the Firefox version number of the closest Firefox release. https://bugzilla.mozilla.org/show_bug.cgi?id=384721 They want to do this because a number of sites sniff for "Firefox".
This is somewhat controversial, because historically the Mozilla project's line on browser sniffing has been:
1) Don't sniff at all 2) If you must sniff, use object sniffing 3) In the rare cases that doesn't work, use the Gecko version
Changing Camino would be construed as giving up on that line. So it was requested in the bug that a discussion be started.
Some questions it might help to consider when assessing the scale of the problem:
- Is it OK if a site warns you that your browser has not been tested, but allows you to continue anyway?
- What about sites (e.g. banks) for which lack of support for Camino is a deliberate policy?
- Does it matter how serious the problem is? I.e. total site blockage vs. lack of flyout submenus on msnbc.com?
Useful documents for the discussion -----------------------------------
Tracking bug for sites which sniff for "Firefox": https://bugzilla.mozilla.org/show_bug.cgi?id=334967 (Note: not all bugs in this list are relevant here - e.g. some correctly exclude Camino, like rollyo.com, bug 337056)
Before there is a lot of discussion here, I would like to see an explanation of how this is a layout issue. David Baron made the assertion that this is a content handling issue, and thus outside the jurisdiction of the Camino team, but I'm having a hard time understanding how our user agent could be construed to affect the handling of any given web content.
If people want to discuss whether their opinion is that it's a good idea or not, in an academic sense, that's fine, but if the discussion is going to be framed in terms of whether or not we are allowed to make this change, someone first needs to provide a compelling argument why the decision of Mike Pinkerton and myself (the Camino module owners) is not relevant.
Gervase Markham wrote: > The Camino team would like to change their user agent string to add the > Firefox version number of the closest Firefox release. > https://bugzilla.mozilla.org/show_bug.cgi?id=384721 > They want to do this because a number of sites sniff for "Firefox".
s/would like to/is going to
(see below)
> This is somewhat controversial, because historically the Mozilla > project's line on browser sniffing has been:
> 1) Don't sniff at all > 2) If you must sniff, use object sniffing > 3) In the rare cases that doesn't work, use the Gecko version
Camino's not changing the Mozilla project's view of browser sniffing. Not in any way should this be misinterpreted to mean that any Camino team member believes those ideals aren't true.
> Changing Camino would be construed as giving up on that line. So it was > requested in the bug that a discussion be started.
Camino is a mozilla.org project, yes, but it's also it's own project with it's own rules and it's own UA that can be changed at will (see my comments on the spec below) by the Camino team.
> Some questions it might help to consider when assessing the scale of the > problem:
> - Is it OK if a site warns you that your browser has not been tested, > but allows you to continue anyway?
My answer would be "hell no". There is no way it's OK. Maybe it is for you, but for end-users, this experience sucks. I think (hope) we can all agree with that.
> - What about sites (e.g. banks) for which lack of support for Camino is > a deliberate policy?
Until we try it, as the bug mentions, we have no way of knowing what portion of the web legitimately blocks Camino. That's what this change is: a trial. If it's a failure then we can back out the change. But my suspicion is that it won't be.
> - Does it matter how serious the problem is? I.e. total site blockage > vs. lack of flyout submenus on msnbc.com?
To you, maybe it matters. To a user? Definitely not. Do we care about users here or developers? If a user were to download Camino, go to msnbc.com, and see that it didn't perform as well as Firefox or Safari, they'd switch back and give up on Camino, especially if they use msnbc.com five hours a day (or some other large number).
> Tracking bug for sites which sniff for "Firefox": > https://bugzilla.mozilla.org/show_bug.cgi?id=334967 > (Note: not all bugs in this list are relevant here - e.g. some correctly > exclude Camino, like rollyo.com, bug 337056)
Not all of these are about Camino, no. But I think they show the greater issue... more comments below.
The proposal that currently exists follows the spec and I doubt any Camino team member wants to violate that spec. The proposal adds a "vendor comment" to Camino's UA. The Camino project is the vendor here, led by the module owners of Camino.
(Note that other browsers *have* violated the spec. See comment 22 of bug 384721.)
The true issue above is that web developers aren't looking for Gecko. The real world isn't inline with our ideal world. It's no one person or organization's fault, but it *is* the reality we live in today. The web today looks for Internet Explorer and Firefox, with a few websites still checking for Netscape and some even being kind enough to look for other specific user-agent strings. Sure, there are many, many web developers who specifically check for a Gecko rv or even do a check for specific features that a browser supports. It's clear that a good portion of sites don't do that, however. It's easier for them to check for specific browsers they want to support.
(And, I'll concede that maybe it's not easier -- I honestly don't know -- but that appears to be the perception of a majority of web developers.)
Camino here has decided that in more cases than not, we're exactly the same as Firefox and should be treated as such. We won't know until we ship some builds (nightly, not releases) with our vendor comment added and see what breaks. I'm guessing that the reported bugs for this will be far less than the reported bugs for sites "not support Camino" when in reality they could.
We all know this sucks. Gerv, you know it sucks. I know it sucks. David knows it sucks. The entire Camino team dislikes it. But our users are crying for it, whether they realize it or not. Is there another short-term solution? Point me to one.
In the long-term, what can we do? How do we make web developers more responsible?
One idea is to rethink the idea of a user-agent string. What information in a UA is actually important? If we want web developers to check based on the Gecko rv in the UA instead of the product name, why do we ship the product name in the UA at all? I can see marketing reasons (market share, etc), but are there technical ones? What if we shipped a release with only "Gecko/20070515 rv:1.8.1.4" as it's user-agent? How much of the web would break? We've seen time and time again that web developers even check what operating system you're running. Now, we all know that Firefox is (mostly) the same on all platform, but apparently they don't.
(Note that the idea above would require us to either break or modify the user-agent string specification, which I fully understand.)
Another idea (credit to timeless) is to ship an extension (on by default) with Firefox that changes the product name in the UA randomly. We could, for fun, change other parts of the UA, thus requiring web developers to check specifically for the part that doesn't change: the Gecko rev and information.
I bet, in the above scenario, the web would break in some pretty serious ways. Would developers respond? How fast? How long did it take for them to start supporting Firefox in the first place? I can imagine the lag wouldn't be as long as previously, but I bet it'd be significant.
In comment 25 of bug 384721, David says the following:
> Firefox owners don't make arbitrary changes to Gecko over the > objections of Gecko module owners; I don't see why Camino should > be different.
To that, I'd assert that if either of the ideas I mentioned above (or something similar) were proposed by Gecko module owners, neither would get implemented. Either one could (would?) help improve the overall web, but could also potentially hurt Firefox (again, from a marketing standpoint). If my assertion is incorrect, I'd like to be proven wrong. The reason I believe this is true is because the user-agent string is partially up to the product and not entirely up to Core.
The change proposed in bug 384721 is a win for Camino's users and a loss for the web overall. It's sad, but I believe it needs to be done to improve overall user experience.
Gervase Markham wrote: > This is somewhat controversial, because historically the Mozilla > project's line on browser sniffing has been:
> 1) Don't sniff at all > 2) If you must sniff, use object sniffing > 3) In the rare cases that doesn't work, use the Gecko version
We haven't been very good at pushing this line, in my opinion, certainly not the third item. Does the Mozilla Foundation have evangelists on staff who go to sites and tell them that the Firefox developers say not to sniff for "Firefox"? Or are we hoping that site authors will listen to Camino, etc. users or developers who complain? If so, that's a silly hope, in my opinion.
> - Is it OK if a site warns you that your browser has not been tested, > but allows you to continue anyway?
It's better than the alternative of not allowing access at all, but definitely sub-par.
> - What about sites (e.g. banks) for which lack of support for Camino is > a deliberate policy?
I can't think of a good reason for this policy, to be honest.
> - Does it matter how serious the problem is? I.e. total site blockage > vs. lack of flyout submenus on msnbc.com?
Probably not to users, no.
I really wish we _did_ randomize the product name from the very beginning, or not ship one at all. I think the fact that we have by-default undermines our attempts to evangelize point #3 above, even if we were trying to it. Which we aren't, that I can see.
Boris Zbarsky wrote: > We haven't been very good at pushing this line, in my opinion, certainly > not the third item. Does the Mozilla Foundation have evangelists on > staff who go to sites and tell them that the Firefox developers say not > to sniff for "Firefox"? Or are we hoping that site authors will listen > to Camino, etc. users or developers who complain? If so, that's a silly > hope, in my opinion.
I agree. I think that a quid pro quo for asking the Camino team not to do this, would be finding some TE resource to deal with this specific problem.
>> - What about sites (e.g. banks) for which lack of support for Camino >> is a deliberate policy?
> I can't think of a good reason for this policy, to be honest.
Perhaps not. But we don't know about their internal browser verification and security processes. In at least one case, a bank representative has got a Bugzilla account and interacted with developers in the bug, explaining why it works the way it does.
> I really wish we _did_ randomize the product name from the very > beginning, or not ship one at all. I think the fact that we have > by-default undermines our attempts to evangelize point #3 above, even if > we were trying to it. Which we aren't, that I can see.
So perhaps the right thing to do is to remove the Firefox name from the UA string? If Firefox itself did it, the web would need to pay attention.
Gervase Markham wrote: > Changing Camino would be construed as giving up on that line. So it was > requested in the bug that a discussion be started.
My view: up to now, UAs have been in continuous retreat, with greater lengthenings. First there was Mozilla/X.X - but then too many people sniffed that, and so it got stuck. And so on.
At last, we've finally figured out that what people should be looking for is rendering engines, not browser versions. WebKit has WebKit/foo, Gecko has Gecko/bar, and so on. This has the potential to stop this ridiculous ever-lengthening UA string problem.
It would be a great shame to give up on that for the sake of a small handful of sites. And it is a small handful - the bug in question had 29 dependencies last time I looked, and not all of them are relevant to Camino.
On the other hand, as I said in another message, we need to do better than just tell the Camino team to suck it up. And I hope we can come up with a plan for that.
Samuel Sidler wrote: > Camino's not changing the Mozilla project's view of browser sniffing. > Not in any way should this be misinterpreted to mean that any Camino > team member believes those ideals aren't true.
"These are my principles. If you don't like them, I have others"?
There's no point having ideals if you abandon them in practice; you are just showing they aren't actually your ideals.
You can disagree with the project's policy if you like; but you can't both agree with it and propose what you are proposing.
> Camino is a mozilla.org project, yes, but it's also it's own project > with it's own rules and it's own UA that can be changed at will (see my > comments on the spec below) by the Camino team.
I think that the collision of "Camino is a mozilla.org project" and "Camino is its own project" is what has led to this debate. Exactly where the UA string falls in that is the question at hand.
>> - Is it OK if a site warns you that your browser has not been tested, >> but allows you to continue anyway?
> My answer would be "hell no". There is no way it's OK. Maybe it is for > you, but for end-users, this experience sucks. I think (hope) we can all > agree with that.
Why so, if it's the truth? Camino is not Firefox - you would be the first to admit that - and so it's possible that there will be things that work in Firefox but don't in Camino. Perhaps you have come across them yourselves in your bug fixing.
>> - What about sites (e.g. banks) for which lack of support for Camino >> is a deliberate policy?
> Until we try it, as the bug mentions, we have no way of knowing what > portion of the web legitimately blocks Camino.
I don't understand how your point follows from my question. I was talking about banks who have specifically told us they are blocking Camino - no UA string change is required to find this out.
How does changing the UA help you distinguish between a legitimate and an illegitimate block?
> The proposal that currently exists follows the spec and I doubt any > Camino team member wants to violate that spec.
I didn't imply that it didn't; I linked to it, if anything, to show that it didn't.
> (Note that other browsers *have* violated the spec. See comment 22 of > bug 384721.)
If those other browsers are not part of the Mozilla project (again, the same question arises), then their behaviour cannot be something we worry about.
> The true issue above is that web developers aren't looking for Gecko.
Sorry, but that's rubbish. If all we have are 29 sites which are broken, then the fact is that the vast majority of web developers _are_. Find any of the new DHTML Ajax libraries, used to build hundreds of sites. They all check for Gecko, and I assume they work fine in Camino.
> One idea is to rethink the idea of a user-agent string. What information > in a UA is actually important? If we want web developers to check based > on the Gecko rv in the UA instead of the product name, why do we ship > the product name in the UA at all?
That's a very, very good question.
> I can see marketing reasons (market > share, etc), but are there technical ones?
If people want to judge market share, we can make sure that each release we do has a slightly unique Gecko date (a day apart or whatever). Then stats people can distinguish, although most people won't care. Because the date would change with every sub-release, people would never look for specific dates for sniffing purposes. They could still do >=, but we're fine with that.
> (Note that the idea above would require us to either break or modify the > user-agent string specification, which I fully understand.)
Hey, we wrote it :-) Of course, there's parsing code out there. So we need to be careful. But with warning, we might be able to come up with something.
> Sorry, but that's rubbish. If all we have are 29 sites which are broken, > then the fact is that the vast majority of web developers _are_.
We have a lot more than that. I've been answering reading Camino feedback, forums, etc. for a very long time. I always tell users to complain to the sites' admins, but I don't file TE bugs on every single on of those sites, because I don't have the time to spend filing bugs that will either sit and rot with no action taken, or in some cases be closed as (essentially) "we don't care about sites that are sniffing".
As for sites that want to choose to block Camino explicitly, there's nothing stopping them from doing so after we change our UA, as it will still contain the word Camino. This way, they'll just have to actually decide to do it, rather than blocking us by omission.
Gervase Markham wrote: > Gervase Markham wrote: >> Changing Camino would be construed as giving up on that line. So it >> was requested in the bug that a discussion be started.
> My view: up to now, UAs have been in continuous retreat, with greater > lengthenings. First there was Mozilla/X.X - but then too many people > sniffed that, and so it got stuck. And so on.
> At last, we've finally figured out that what people should be looking > for is rendering engines, not browser versions. WebKit has WebKit/foo, > Gecko has Gecko/bar, and so on. This has the potential to stop this > ridiculous ever-lengthening UA string problem.
> It would be a great shame to give up on that for the sake of a small > handful of sites. And it is a small handful - the bug in question had 29 > dependencies last time I looked, and not all of them are relevant to > Camino.
> On the other hand, as I said in another message, we need to do better > than just tell the Camino team to suck it up. And I hope we can come up > with a plan for that.
I think the idea of removing Firefox from the version string is a possible solution to this. We could do that for Firefox 3, starting with the next alpha. As a major release, and a major rev in Gecko, it will get plenty of attention. We can have some people write web developer articles on our UA sniffing policy and why we have it ("keeping the web open" and "preserving choice and innovation"!) and how to check for Gecko in the UA string, and publish those over the summer, to make sure more web developers sit up and pay attention. I'm volunteering right now to provide editorial review to anyone who does that. :)
If we find that the Web really can't take it, we can put Firefox back in the UA string with the first post-3.0 security release and let Camino do the same.
Meanwhile, let's see if this can get webmasters to fix their sniffing code. This is totally in line with our overall mission as an organization; I think we should try it.
On Jun 19, 3:41 am, Gervase Markham <g...@mozilla.org> wrote:
> I think that the collision of "Camino is a mozilla.org project" and > "Camino is its own project" is what has led to this debate. Exactly > where the UA string falls in that is the question at hand.
Once again, I would like an explanation of why there is a question. It's a change within the Camino portion of the tree, it has absolutely no direct effect on any other product or shared component, it violates no web standards, and we have been told there are no legal issues.
It's fantastic that this has sparked discussion of having real weight put behind the evangelism effort, and we (the Camino team) will certainly watch where this discussion goes and adjust our plans accordingly--as Sam said, all of us would rather see the need for this kind of hack to go away, rather than using the hack--but these repeated vague claims that somehow the standard module ownership system does not apply here, without any explanation of why (and again, why is this in m.d.t.layout?) are really frustrating.
If you'd like to discuss this offline that's fine, but unless someone can give a substantive argument it would be very helpful if this discussion could stop being framed in terms of the community's right to dictate Camino policy to the Camino developers and owners.
On Jun 19, 10:22 am, smorgan <stuart.mor...@gmail.com> wrote:
> Gerv wrote: > > Sorry, but that's rubbish. If all we have are 29 sites which are broken, > > then the fact is that the vast majority of web developers _are_.
> We have a lot more than that. I've been answering reading Camino > feedback, forums, etc. for a very long time. I always tell users to > complain to the sites' admins, but I don't file TE bugs on every > single on of those sites, because I don't have the time to spend > filing bugs that will either sit and rot with no action taken, or in > some cases be closed as (essentially) "we don't care about sites that > are sniffing".
Just to reiterate what Stuart said here, bug 334967 is just the tip of the iceberg. Its deps are either TE bugs that were originally filed against Camino and which I added to the tracking bug when I learned of it, other TE bugs I've happened upon randomly when searching for something someone's reported and which matched the issue, and a few bugs added by other (non-Camino) triagers who happen to know about the tracking bug. To my knowledge, no-one's made any concerted effort to go through open TE bugs and pull out all the sniffing-related ones that have been filed since TE was opened. Moreover, every site that sniffs and gets filed in Bugzilla doesn't get kicked to TE; rather than flood TE with so many bugs that the major sites get lost in the noise (or, lost more than than they are now in the morass that is TE), many just get closed INVALID.
By contrast, I think we see about 1 site per week in the Camino forum (and I don't read the feedback list, but I'd guess it's at least that there, too). As Stuart notes, we always request people write to webmasters and point them at http://www.geckoisgecko.org (started by a Camino user, btw).
I'm delighted to see interest in actually doing something about the problem of sniffing, but it's going to need some serious commitment from those who care about Gecko and have resources and clout to leverage.
For example, I would have loved to see outrage (and education efforts) from the organization that shepherds Gecko when http://developer.yahoo.com/yui/articles/gbs/ first came out in early 2006; it was a squandered opportunity to push "rendering engines" instead of "browsers" (that page illustrates everything that is wrong with people who *think* they're actually performing best-practice detection these days, and if you send different code to different browsers [based on rendering engines], what code do you send to X-grade browsers? Gecko code? WebKit code? Random generic code?). Instead, we're left with a situation where Yahoo properties work correctly with Firefox but not other Gecko browsers, and each different property has to be evangelized separately (and, really, for each browser on each property, since they tend to ignore "sniff for rendering engine" and just add each new complaining browser, when they deign to add at all). As I recall, the BBC announced a very similar policy at the same time. We can complain, but since we're not Firefox (or Safari, or IE), not A-Grade browsers, it doesn't really matter.
And, as I mentioned in bug 334967 when I introduced http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko , the existing "when and how to sniff" documentation in http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Brow... is in need of a serious upgrade. Too much time and effort is spent on differentiating Mozilla from Netscape 4, and the amount of time the document spends on describing sniffing for different UA string components seems to run counter to the goals of no sniffing/feature sniffing/rendering engine and engine version sniffing trio (which aren't, in my opinion, adequately stressed in that document). As I said in the bug, I'm not the right person from a technical perspective to write or revise the doc, but I'm happy to help, and rather than simply complaining, I did draft http://wiki.mozilla.org/User:Sardisson/Gecko_is_Gecko as an idea of what I think would be better (also, thanks to Boris for the edits he made).
Also, once the existing sniffing document is fixed (or replaced), it (or its successor) needs its visibility raised; you can only find that page in DevMo if you're specifically looking for it, which seems less- than-helpful if we want to promote "no sniffing" as our first ideal.
But all of this takes time, both in person-hours and, worse, in lifespans of old ideas. In the absence of any meaningful efforts on the sniffing-education front now (or, really, in the last four years) by those with leverage, we need to do what's best for Camino users right now. That we have to, and what we need to do to do that, sucks. My hope is that it is only a temporary hack....
> it has absolutely > no direct effect on any other product or shared component,
It most certainly does, since it increases the pressure on other non-Firefox Gecko apps to make the same change.
It's also primarily an issue about what we send over the wire to Web sites, a topic that's primarily a Gecko issue and on which the Gecko module owners are more likely to be experts.
-David
-- L. David Baron <URL: http://dbaron.org/ > Technical Lead, Layout & CSS, Mozilla Corporation
> > it has absolutely > > no direct effect on any other product or shared component,
> It most certainly does, since it increases the pressure on other > non-Firefox Gecko apps to make the same change.
I used the word "direct" very deliberately. That's an indirect effect, and all kinds of things have indirect effects on other browsers. As a concrete example, we get pressure from some users to implement things like middle-click-to-close-tabs because of Firefox having done it, but I don't think that means that I should be able to override mconnor when I disagree with Firefox UI.
> It's also primarily an issue about what we send over the wire to Web > sites, a topic that's primarily a Gecko issue and on which the Gecko > module owners are more likely to be experts.
If there is a technical reason that vendor comments are problematic, then why is there an API for adding them? I haven't heard any arguments based on technical expertise that we lack, just a difference of opinions a philosophical issue based on well-established facts that we all understand.
Gervase Markham wrote: > So perhaps the right thing to do is to remove the Firefox name from the > UA string? If Firefox itself did it, the web would need to pay attention.
This seems like a great idea to me. The only good reason I can see to not do this is that there are some sites that might want to sniff out the product for the purpose of delivering appropriate extensions (AMO, Google toolbar, etc). I was discussing this with Sander and he suggested that the app's GUID be exposed as part of the user agent (or I guess as another |naviagator| property) so that sites with interest in delivering extensions could sniff that out (if they're making extensions, they'd know that anyway). A webmaster that really wanted to sniff out firefox and block non-firefox apps could still do so, but it would be harder and perhaps too hard for the low-IQ webmasters that typically use sniffing now. I guess some "helpful" person might still add GUID sniffing as part of a larger browser sniffing JS library and then we're back to square one.
Anyway, as a user and developer of SeaMonkey (which is as far as I know afflicted by all the same boneheaded sites that Camino is), I would oppose putting Firefox in the UA (like Firefox? I hope not!). And I would welcome the removal of the product name from the UA.
Gervase Markham wrote: > At last, we've finally figured out that what people should be looking > for is rendering engines, not browser versions. WebKit has WebKit/foo, > Gecko has Gecko/bar, and so on. This has the potential to stop this
Gecko/bar is not too useful without rv:foo on other side of user-agent string, because bar is just build date. Build date is same for builds from different branches: if I'll build tomorrow from 0.9.1, 1.0.0, 1.4, 1.7, 1.8, 1.8.1 and trunk, all builds will have "Gecko/20070623".
Boris Zbarsky wrote: > I really wish we _did_ randomize the product name from the very > beginning, or not ship one at all. I think the fact that we have > by-default undermines our attempts to evangelize point #3 above, even if > we were trying to it. Which we aren't, that I can see.
Just for curiosity...
In reality, product name of Firefox *is* randomized over its user base. For example this is detection code for one version of Firefox on web traffic analysis service:
<pattern>^Mozilla/5\.0 \(.*\) Gecko/.* (Butt|Fire|Free|Hidden|...|Sun|...|Thunder|Turbo|Water|Web)(aardvark|adder| ...|bird|...|worm|yak|zebra)/2\.0\.0\.4</pattern> // "..." stands for really long list of variants provided by // Firesomething extension
> Gervase Markham wrote: >> So perhaps the right thing to do is to remove the Firefox name from >> the UA string? If Firefox itself did it, the web would need to pay >> attention.
> This seems like a great idea to me. The only good reason I can see to > not do this is that there are some sites that might want to sniff out > the product for the purpose of delivering appropriate extensions (AMO, > Google toolbar, etc). I was discussing this with Sander and he > suggested that the app's GUID be exposed as part of the user agent (or I > guess as another |naviagator| property) so that sites with interest in > delivering extensions could sniff that out (if they're making > extensions, they'd know that anyway).
A simpler solution, I think, would be to drop "Firefox/x.x.x.x" from the UA string, but leave the product name in place for other apps (Camino, SeaMonkey, Thunderbird). Basically, let's re-use the late Mozilla Suite's UA string for Firefox.
So, imagine we had implemented this solution in 1.8. Firefox 2.0.0.4 with this scheme would just have been:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; pl; rv:1.8.1.4) Gecko/2007051502
but Camino's UA string wouldn't need any changes:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; pl; rv:1.8.1.4) Gecko/20070509 Camino/1.5 (MultiLang)
This way, stats companies can still easily differentiate between Firefox and non-Firefox apps (so you won't serve a SeaMonkey extension to a Firefox user), but ignorant web developers would need to specifically block Camino or SeaMonkey.
In a sense, this is what Camino developers wanted - full Firefox UA string in the Camino one. ;-)
On Jun 19, 3:41 am, Gervase Markham <g...@mozilla.org> wrote:
> Samuel Sidler wrote: > > Camino's not changing the Mozilla project's view of browser sniffing. > > Not in any way should this be misinterpreted to mean that any Camino > > team member believes those ideals aren't true.
> "These are my principles. If you don't like them, I have others"?
> There's no point having ideals if you abandon them in practice; you are > just showing they aren't actually your ideals.
> You can disagree with the project's policy if you like; but you can't > both agree with it and propose what you are proposing.
If this is true, then everyone on the entire Mozilla project who ever worked on quirks mode compatibility bugs doesn't believe that standards-compliance is a good thing for the internet. Is that your assertion?
Andrew Schultz wrote: > Anyway, as a user and developer of SeaMonkey (which is as far as I know > afflicted by all the same boneheaded sites that Camino is), I would > oppose putting Firefox in the UA (like Firefox? I hope not!).
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/20070620 SeaMonkey/2.0a is better than Firefox/3.0a4" ;)
smorgan wrote: > If this is true, then everyone on the entire Mozilla project who ever > worked on quirks mode compatibility bugs doesn't believe that > standards-compliance is a good thing for the internet. Is that your > assertion?
No, that doesn't follow, because they are _quirks_mode_ compatibility bugs.
If someone suggests putting compatibility fixes of that sort into standards mode, there's normally a pretty big pushback. The reason we _have_ quirks mode is so that we can also have a standards-compliant mode which does the right thing. If we only had one mode, it would be much worse for the Internet's standards compliance.
Adam Hauner wrote: > In reality, product name of Firefox *is* randomized over its user base. > For example this is detection code for one version of Firefox on web > traffic analysis service:
Traffic analysis tries to extract versions too, and is paid for based on how accurate it is, thus has incentive to be as complete as possible. Web sites just care about the "most common" versions, typically. I would be surprised to find a site sniffing for "BonEcho", much less "Turboaardvark".
Adam Hauner wrote: > Gecko/bar is not too useful without rv:foo on other side of user-agent > string, because bar is just build date. Build date is same for builds > from different branches: if I'll build tomorrow from 0.9.1, 1.0.0, 1.4, > 1.7, 1.8, 1.8.1 and trunk, all builds will have "Gecko/20070623".
Worse is if a Linux vendor builds FF2 from the exact release-tagged sources today they get an entirely different Gecko/ date. Useless.
The date was intended to say something about the source; it was instead implemented as a build date since that was easier. For official Mozilla/Netscape builds the difference was negligible, but when the published tarballs are used by others they get incorrect results.
On Jun 27, 9:21 am, Gervase Markham <g...@mozilla.org> wrote:
> No, that doesn't follow, because they are _quirks_mode_ compatibility bugs.
> If someone suggests putting compatibility fixes of that sort into > standards mode, there's normally a pretty big pushback. The reason we > _have_ quirks mode is so that we can also have a standards-compliant > mode which does the right thing.
I think it does follow, but I apparently wasn't clear on why:
Web standards currently exist, and have for a while. Clearly we want authors to create pages using standards, as opposed to continuing to use non-standard pages. Given that, the arguments for and against quirks mode are essentially: Pro: There are pages out there, both old and new, that are not standard-compliant, and not rendering them in a useful way for the user creates a bad user experience for users of Gecko-based browsers. Good quirks-mode rendering lets users use more web pages. Con: If compatibility of pages that are not standards compliant is good, then authors have little incentive to fix their broken pages. Good quirks-mode rendering reduces pressure on authors to do the right thing.
Good ways of doing client-capability-detection exist, and have for a while. Clearly we want authors to use them, as opposed to continuing the practice of checking the browser name. Given that, the arguments for putting Firefox in other Gecko user agents are: Pro: There are page out there, both old and new, that are looking for the word Firefox, and not providing it creates a bad user experience for users of non-Firefox Gecko-based browsers. Adding it lets users use more web pages. Con: If non-Firefox browsers pass the UA checks, then authors have little incentive to fix their broken pages. Adding it reduces pressure on authors to do the right thing.
Those are very much parallel, and I really don't think I've misrepresented either case.
> If we only had one mode, it would be much worse for the Internet's standards compliance.
Agreed, but the analogous action to "one mode" for us to take would be to remove the Gecko string and version from our UA while adding Firefox so that sniffing for the word Firefox was the *only* way to detect Camino. What we are doing will provide a UA that works when sniffed the recommended way, or when sniffed the wrong way. That seems very much the same as proving an engine which can render both standards-compliant content and non-compliant content.
