More and more sites are using totally bogusly broken server-side sniffing for Palm Pre which causes us to at best get the wrong content and at worst get a blank page back. Nothing we can do about that, so we need to stop using the "pre" string to make nightlies more useful for testing. :( I realize there may be issues with AUS and such, right? But can we just change what we send on the HTTP wire without changing anything else? I'd even be fine with having navigator.userAgent say "pre" as long as the UA header on the wire doesn't, if that makes life simpler.

Adding contacts AMO and RelEng, and Mossop. IIRC, the "pre" prefix was mostly added for our own tracking purposes (AUS ping) as well as Add-On compatibility purposes. I'm happy to stop reporting it externally so long as that doesn't affect our ability to monitor nightly usage.

I don't believe the User-Agent header has any effect on AUS, nor do I think it would effect the main add-ons manager or any add-ons really. AMO may see problems with their magic install button that detects your version, but I'll let them comment there. In terms of monitoring nightly usage I would have thought that monitoring pings to the nightly update channel would do that better than relying on the UA string while users are able to munge to their hearts content.

We look for this in navigator.userAgent: var UA_PATTERN_FIREFOX = /Mozilla.*(Firefox|Minefield|Namoroka|Shiretoko|GranParadiso|BonEcho|Iceweasel|Fennec|MozillaDeveloperPreview)\/([^\s]*).*$/; We look for Win32|Mac|Linux in navigator.platform. We use whatever was in the ua capture group to say "This add-on does not support Firefox <version>". If you take out "pre" the message is going to be incorrect, but only QA people will complain.

The two troublesome cases I can think of are: * someone using 4.0b2 installing an add-on with a maxVersion of 4.0b2pre * someone using 4.0b2pre installing an add-on with a minVersion of 4.0b2 In these cases we would show the add-on as compatible and installable, but Firefox would give them an error if they try to install it unless they've disabled compatibility checking. I'm okay with these edge cases though. This should be fine to remove from AMO's side.

See also bug 572659

I have to think this over, but my initial feeling is that we need some sort of identifier to bucket crashes by type (nightly vs release, etc), figure out when one was fixed, compare crashes, etc.

Can't we just report that sort of identifier in the breakpad data we send, instead of sending it on the wire in the HTTP headers to every single website?

Yeah, and I'm not even sure we need to do that, assuming we use product-details and/or had a system that could act as the release date truth.

We could also change the "pre" to something else ("4.0b5almost"!). Or we could decide that not very many people are going to keep building specialized content for the Palm Pre, ahem.

If we do this, it has to be soon. See bug 586165.

Since this only affects nightly builds, we can do it at any time without regard for the beta schedule. I think there's lots of pieces of our infrastructure which key off of "pre" in our version numbers, and I'm not sure it's worth changing all that to fix this bug (certainly not before FF4).

We could go back to using '+' instead: "1.9.2.8+" rather than "1.9.2.9pre". I think our update code still copes with that format, even. Then again, there was probably a reason we changed that.

The other option might be to add a one-character identifier for the nightly builds (how about 'n'?), which makes it less likely to be mixed up with some other UA items. Thus, current nightlies would be "1.9.2.9n" and "2.0b5n" for identification as such. This hopefully won't match any mobile token any more.

> Or we could decide that not very many people are going to keep building > specialized content for the Palm Pre, ahem. I think this depends on how you define "not very many" and "specialized content". We've had several sites now blocking "pre" completely (just returns a 5xx HTTP error for any request with such a UA).

(In reply to comment #14) > I think this depends on how you define "not very many" and "specialized > content". We've had several sites now blocking "pre" completely (just returns > a 5xx HTTP error for any request with such a UA). That's behavior we should not react to by more or less encouraging it but by getting in contact and trying to get this undone or else ignore it (or even make it more usable, e.g. by sending "pre" with our releases or such), as that behavior is completely contrary to our mission of an open web that is equally accessible to anyone. Doing what they seem to do, i.e. excluding people by UA, is pure racism and not better than excluding black people from entry.

(In reply to comment #14) > > Or we could decide that not very many people are going to keep building > > specialized content for the Palm Pre, ahem. > > I think this depends on how you define "not very many" and "specialized > content". We've had several sites now blocking "pre" completely (just returns > a 5xx HTTP error for any request with such a UA). Why oh why would *anyone* do that? That being said, I think what these websites need is indeed evangelism, rather than us wrapping ourselves around their brokenness. Depending on how frequent it is though (do we have any real-life examples?), dropping "pre" might be a good idea for the sake of robustness (like we do with parsing broken HTML), but without some data, I can't support breaking legitimate uses of UA sniffing (read: AMO, Fx Input) to fix illegitimate uses. (Though I am elaborately agreeing with comment 15 here, I could not just write "+1" due to the horribly misplaced and best quickly forgotten skin color metaphor).

> do we have any real-life examples? Bug 582630 is a real-life site (appstorehq.com) which doesn't render at all with "pre". bug 582264, bug 576936, bug 572035, bug 571755 are real-life sites (everything under live.com, ing direct, hotmail) rendering their "mobile" version in anything with a "pre" in the UA string. That's in 30 seconds of searching in tech evang on bugs with "palm" in the comments. I seem to recall there were a few more bugs. Please do feel free to evangelize all of the above, but note that several of them seem to be using some sort of common server-side sniffing code, so the real people to evangelize are the makers of that code... whoever they are.

Seems to be a much more common problem than I expected. I'm with comment 9 then -- until the Palm "Almost" is released, followed by the "Soon", "in-a-little-while", and "cant-be-long-now".

live.com et.c seems to be the same broken UA sniffer from some .NET classes that also heavily breaks every XHTML-aware browser with with "Firefox" in its UA string. We should get in touch with the group probably at MS who is doing that broken module anyhow.

This is so easy to fix and such a pointless use of resources for evang. We'll just fix it and be done.

(Don't let me discourage you from fighting the good fight, though!)

(In reply to comment #21) > (Don't let me discourage you from fighting the good fight, though!) You are already have. This is just one more stone in the wall I see standing there in front of evang which has "we don't care any more" painted in large letters.

Let me clarify -- I'm referring specifically to the 'pre', since if we fix it there's not much point in evang. Comment 19 is different, that sounds thoroughly worth pursuing. I would hope we care strongly about evang, which is why prioritization is key!

(In reply to comment #11) > Since this only affects nightly builds, we can do it at any time without regard > for the beta schedule. I think there's lots of pieces of our infrastructure > which key off of "pre" in our version numbers, and I'm not sure it's worth > changing all that to fix this bug (certainly not before FF4). We're almost done with 'pre' for Firefox 4 anyway (a few more to go?), so the advantage of fixing this for 4 isn't strong. When the dust settles and we get rolling on 5 would be a great time, and give us some time to make whatever infra changes we need to. (Kinda like dropping minor version, too!)

I've noticed that with the version bumps on mozilla-central (to 6.0a1) and mozilla-aurora (5.0a1) today the "pre" has already been dropped. Was that done intentionally or rather by accident?

This was definitely intentional (aurora is 5.0a2, though, but I see that as a typo on your side) and I think we should resolve this bug as FIXED. I still think that all that sniffing is crazy and us even thinking about removing the "pre" because of dumb sniffing (IMHO sniffing for devices is even worse than sniffing for browser brands), but IMHO we ended up removing it because of our change of development process and that just happens to help avoid that case of dumb sniffing as well, so we're even philosophically "clean" and still ended up doing what was requested here. ;-)

Yep, intentional. "Pre" is dead. Not sure how you want to mark this one (trunk was changed by bug 648653)

Let's mark it as a dupe of the bug that fixed this one, then, esp. as it was probably done for a different overall plan than in comment #0 (though I think people were keeping this one in mind as a case it helps).

(In reply to comment #26) > (aurora is 5.0a2, though, but I see that as a typo on your side) KaiRo, that seems to be intentional as well, due to 5.0 moving to aurora: http://mozilla.github.com/process-releases/draft/development_specifics/#versioning-firefox

rsx11m: Of course it is intentional, but you typoed "5.0a1" in comment #25 ;-)

Ok, now I get it - yeah, I was the stupid one who made the typo, those numbers look all the same (and that new system needs to get used to... :-) ).