UA strings and icons in the new release process
Henri Sivonen
current testing process:
1) Before RC, the UA string contains stuff that won't be in the final
UA string, so when people test Web sites, they are testing with a
different UA string than what end users will use. (Examples of problems
in the wild: disney.com most likely is sniffing for "pre" and thinks
Firefox nightlies are Palm Pre's default browser. wikia.com sniffs for
"4.0b", so their UA sniffing that seemed to work for beta testers
doesn't work with RC or final.)
2) Nightly testers don't get to look at the nice Firefox icon but get a
dull blue globe, so they have to trade away prettiness in order to test
upcoming code.
Chrome doesn't have these problems.
I suggest fixing these problems in the new Firefox release process. That
is, I suggest that when the stable version says "Firefox/5.0" in the UA
string, the beta channel should say "Firefox/6.0", the experimental
channel should say "Firefox/7.0" and the nightly channel should say
"Firefox/8.0" without "pre" or "b" or anything like that so that testing
will represent the sniffing experience the product will have when it
graduates into the stable channel.
Furthermore, I suggest giving the non-stable channels the Firefox icon
and name or, if that's not OK for people who make trademark decisions,
something that is visually as polished as the Firefox icon, so that
nightly testers won't have to trade away prettiness to test early code.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Tiago Sá
name and the Firefox icon can't be applied to Minefield because of
licensing reasons. Minefield is completely redistributable and
modifiable, while Firefox itself isn't, because of the trademark of
the name (although that's the only thing, if you read the license
you'll see that if you change Firefox in a significant way and
redistribute it, you cannot legally redistribute it with the same name
or the same icon/logo). Minefield is, on the other hand, not Firefox
until it is approved by QA for a definite build like a beta build or a
RC (or a final, of course), so it can't be called that or bear its
icon.
Also, Google doesn't do that. Chromium is called Chromium for a
reason, the very same reason why Minefield is called Minefield and not
Firefox. Of course, Chrome isn't open and free like Firefox is, but
that's another matter.
As for the string, I think you have a point, but sniffing for browsers
like the examples you quote isn't doing it the right way, as far as I
know. As far as I know, sites should sniff the engine, not the
browser, and should be way more liberal with their version checks,
because checking for a beta version and not use an asterisk after 4.0
is... well, it's dumb. I don't think you'll find the mozillacorpians
very welcoming of changes to support sniffing malpractices. Just like
when they dropped the locale thingy on the UA string because it
shouldn't be done with sniffing the UA but rather with checking the
browser setting...
> hsivo...@iki.fihttp://hsivonen.iki.fi/
Asa Dotzler
> I don't answer for Mozilla Corp but I can tell you that the Firefox
> name and the Firefox icon can't be applied to Minefield because of
> licensing reasons. Minefield is completely redistributable and
> modifiable, while Firefox itself isn't
This is not a problem. Mozilla can continue to make (if it chooses to) a
trademark free binary.
Also, I believe this is being worked on.
>
> Also, Google doesn't do that. Chromium is called Chromium for a
> reason, the very same reason why Minefield is called Minefield and not
> Firefox. Of course, Chrome isn't open and free like Firefox is, but
> that's another matter.
There is no requirement that we follow Chrome on this.
> I don't think you'll find the mozillacorpians
> very welcoming of changes to support sniffing malpractices.
Henri isn't asking for better support for sniffing malpractices. He's
asking for a more accurate user agent string for pre-release versions.
- A
Philipp von Weitershausen
On Mon, Mar 21, 2011 at 12:30 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> We have a couple of (minor) problems with UA strings and icons in the
> current testing process:
>
> 1) Before RC, the UA string contains stuff that won't be in the final
> UA string, so when people test Web sites, they are testing with a
> different UA string than what end users will use. (Examples of problems
> in the wild: disney.com most likely is sniffing for "pre" and thinks
> Firefox nightlies are Palm Pre's default browser. wikia.com sniffs for
> "4.0b", so their UA sniffing that seemed to work for beta testers
> doesn't work with RC or final.)
>
> 2) Nightly testers don't get to look at the nice Firefox icon but get a
> dull blue globe, so they have to trade away prettiness in order to test
> upcoming code.
>
> Chrome doesn't have these problems.
>
> I suggest fixing these problems in the new Firefox release process. That
> is, I suggest that when the stable version says "Firefox/5.0" in the UA
> string, the beta channel should say "Firefox/6.0", the experimental
> channel should say "Firefox/7.0" and the nightly channel should say
> "Firefox/8.0" without "pre" or "b" or anything like that so that testing
> will represent the sniffing experience the product will have when it
> graduates into the stable channel.
I would argue for the exact opposite. Despite the fact that nightlies
come as "Minefield" with a different logo and say "4.0b8pre" or
something, we've had lots of people assume in bug reports that they
were running a released "4.0b8" or even "4.0". I think the branding of
the various channels should be unmistakably clear and *not* include a
version number.
That said, I agree that we should ship nightlies with a prettier icon
and the Firefox branding *including* the channel, though: "Firefox
experimental", "Firefox beta", etc.
> Furthermore, I suggest giving the non-stable channels the Firefox icon
> and name or, if that's not OK for people who make trademark decisions,
> something that is visually as polished as the Firefox icon, so that
> nightly testers won't have to trade away prettiness to test early code.
So long as we don't create the illusion that they're running a
supported product. "Firefox experimental" is what it is, no warranty,
your mileage may vary, etc. In fact, to make the distinction even
clearer, I have been arguing that by default nightlies should operate
in a different profile than a stable release.
Mike Beltzner
> On 3/21/2011 7:36 AM, Tiago Sá wrote:
>> I don't answer for Mozilla Corp but I can tell you that the Firefox
>> name and the Firefox icon can't be applied to Minefield because of
>> licensing reasons. Minefield is completely redistributable and
>> modifiable, while Firefox itself isn't
>
> This is not a problem. Mozilla can continue to make (if it chooses to) a trademark free binary.
It's not *the* problem. We choose to not brand nightlies as Firefox because we cannot make the guarantee that they will provide the security, stability and user experience associated with that brand.
That decision can always be revisited, but I think we still want:
- mozilla-central builds to be branded differently [1]
- mozilla-experimental builds should be branded as "experimental" [2]
- mozilla-beta builds to be clearly branded as "beta" [2]
- final builds to be branded as Firefox [2]
> There is no requirement that we follow Chrome on this.
No, but I think their model is good, actually, modulo the difficulty in changing update streams. I also agree with Henri that we should change our strategy of appending the beta/non-beta status in the UA string, as it's causing endless headaches from a technology evangelism perspective.
cheers,
mike
[1]: I chose "Minefield" many moons ago because I wanted to signal that there was some risk to running the builds. I'd be happy for a different name, like "Mozilla Browser" or "Mozilla Trunk", if people want. I also think we can be playful with the logo, showing it in various levels of "construction" - initially as wireframe, then with some of the earth and fox "skin", etc.
[2]: I think where possible we should de-emphasize the actual version number. Those running these builds should always be up to date on the latest experimental, beta, or Firefox version, period. Chrome gets this absolutely right. Version numbers are for developers and support, users just need to know which "product" they are running.
Boris Zbarsky
> I would argue for the exact opposite. Despite the fact that nightlies
> come as "Minefield" with a different logo and say "4.0b8pre" or
> something, we've had lots of people assume in bug reports that they
> were running a released "4.0b8" or even "4.0". I think the branding of
> the various channels should be unmistakably clear and *not* include a
> version number.
I see absolutely no reason why we should be forced to show the same
information to web sites as we show to the user in terms of version
information. Henri's proposal concerns what websites see. I think we
should strongly consider something like his proposal; we waste a fair
amount of time just triaging issues that have to do with broken
browser-sniffing of the sort he describes.
-Boris
Colby Russell
> On 3/21/2011 7:36 AM, Tiago S� wrote:
�
>> Also, Google doesn't do that. Chromium is called Chromium for a
>> reason, the very same reason why Minefield is called Minefield and not
>> Firefox. Of course, Chrome isn't open and free like Firefox is, but
>> that's another matter.
>
> There is no requirement that we follow Chrome on this.
The context was
> Nightly testers � have to trade away prettiness in order to test
> upcoming code.
>
> Chrome doesn't have these problems.
--
Colby Russell
Philipp von Weitershausen
> On 3/21/11 11:25 AM, Philipp von Weitershausen wrote:
>>
>> I would argue for the exact opposite. Despite the fact that nightlies
>> come as "Minefield" with a different logo and say "4.0b8pre" or
>> something, we've had lots of people assume in bug reports that they
>> were running a released "4.0b8" or even "4.0". I think the branding of
>> the various channels should be unmistakably clear and *not* include a
>> version number.
>
> I see absolutely no reason why we should be forced to show the same
> information to web sites as we show to the user in terms of version
> information.
That's a good point. There will still be some people looking at the UA
and confuse their nightly with a final release, but I guess we can't
win them all.
> Henri's proposal concerns what websites see. I think we
> should strongly consider something like his proposal; we waste a fair amount
> of time just triaging issues that have to do with broken browser-sniffing of
> the sort he describes.
Yeah, makes sense.
Christian Legnitto
So a firefox 5 that had 200 nightly builds on m-c, 35 on experimental, and 4 on beta would identify as;
5.4.35.200
At the experimental clone point we'd reset m-c to the next version (6.0.0.0). If we needed to do chemspills they just inherit the number (for versions curretly in development) or start counting after the last released version (if we released Firefox 5 as 5.4.35.200 chemspill builds would start at 5.4.36.200, assuming we didn't go straight to beta...then they'd start at 5.5.35.200)
Again, still thinking it through, but there are many advantages...one of which is an end to UA sniffing issues between trunk and final.
Christian
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Asa Dotzler
> On 03/21/2011 10:20 AM, Asa Dotzler wrote:
> …
>>> Also, Google doesn't do that. Chromium is called Chromium for a
>>> reason, the very same reason why Minefield is called Minefield and not
>>> Firefox. Of course, Chrome isn't open and free like Firefox is, but
>>> that's another matter.
>>
>> There is no requirement that we follow Chrome on this.
>
> The context was
>
> > upcoming code.
> >
> > Chrome doesn't have these problems.
>
We can make nightly builds pretty without using identical icon artwork
or name.
- A
Henri Sivonen
> I don't answer for Mozilla Corp but I can tell you that the Firefox
> name and the Firefox icon can't be applied to Minefield because of
> licensing reasons. Minefield is completely redistributable and
> modifiable, while Firefox itself isn't, because of the trademark of
> the name (although that's the only thing, if you read the license
> you'll see that if you change Firefox in a significant way and
> redistribute it, you cannot legally redistribute it with the same name
> or the same icon/logo).
Well, nightly builds are made by Mozilla and Mozilla controls the
trademark, so if Mozilla so chose, it could apply trademarked branding
to builds earlier in the cycle than in the current practice. It's really
just a matter of what level of code maturity Mozilla is comfortable with
putting the branding on.
> Also, Google doesn't do that.
Actually, Google brands the dev, beta and stable channels as Chrome.
Only the channel less stable than dev is branded differently (Canary).
(Chromium is a different branding axis.)
> As for the string, I think you have a point, but sniffing for browsers
> like the examples you quote isn't doing it the right way, as far as I
> know.
My UA string suggestion isn't about what sites should be doing. It is
about testing the browser in a way that is representative of how stable
releases will interact with Web sites--when real Web sites do silly and
sad things with the UA string. The reality is that if we are testing
with a UA string that differs from what eventually gets shipped, we
aren't testing the Web experience that end users get when the code
emerges as a stable release.
On Mon, 2011-03-21 at 08:25 -0700, Philipp von Weitershausen wrote:
> I would argue for the exact opposite. Despite the fact that nightlies
> come as "Minefield" with a different logo and say "4.0b8pre" or
> something, we've had lots of people assume in bug reports that they
> were running a released "4.0b8" or even "4.0". I think the branding of
> the various channels should be unmistakably clear and *not* include a
> version number.
I have no problem with the product giving more detailed information in
the about box, in about:support or even in a special API that bmo, AMO
and SUMO would be whitelisted to call.
I think we shouldn't expose to random non-Mozilla Web sites the kind of
version detail that sites can only ignore or abuse with no compelling up
side. And further, when we test stuff, I think we should test the kind
of configuration that's going to be shipped, and the UA string,
unfortunately, is a user experience-sensitive part of the configuration.
On Mon, 2011-03-21 at 09:33 -0700, Christian Legnitto wrote:
> For UA string my current thinking is using
> [firefox].[beta].[experimental].[m-c], though I don't have a concrete
> proposal yet.
What use cases does exposing that level of detail to all Web sites
address? Does exposing that level of detail address any use cases that
aren't special to Mozilla's own sites for supporting Firefox?
RyanVM
> I also think we can be playful with the logo, showing it in various levels of "construction" - initially as wireframe, then with some of the earth and fox "skin", etc.
and sensible way to differentiate the different channel builds.
Nicholas Nethercote
>
> [1]: I chose "Minefield" many moons ago because I wanted to signal that there was some risk to running the builds. I'd be happy for a different name, like "Mozilla Browser" or "Mozilla Trunk", if people want. I also think we can be playful with the logo, showing it in various levels of "construction" - initially as wireframe, then with some of the earth and fox "skin", etc.
+1 for this. "Minefield" is not a good name, and the world/bomb icon
is not a good icon -- in both cases it's completely unclear that this
is a Firefox dev build. A name like "Firefox-dev" would be boring but
much clearer.
Nick