User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032505 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032505 Minefield/3.0b5pre The new Add-on pages are not showing the correct OS download link. Nor is the version history page showing all available OS versions for specific Add-ons. For instance, theme "Classic Compact" (https://addons.mozilla.org/en-US/firefox/addons/versions/3699) Has three different versions (Linux, Windows & Mac OS/X), however, only the Linux version is showing up even though I am using Windows XP. Reproducible: Always Steps to Reproduce: 1. 2. 3.

bug 425311 shows the link text is wrong, but the actual download is correct. Still a serious problem.

Yep, I see this too for xforms. The .xpi looks to be the right one, but the Download Now button shows Linux, not Windows.

// BEGIN VERY FRUSTRATED RANT This is really a pretty major bug that should have been fixed right away. Two days (and what will now probably be a whole weekend) is way too long to wait for this bug to be fixed. Basically every Firefox 3.0b5+ compatible theme that is using OS native scrollbars MUST provide different different builds of their themes for Windows and Mac, which means any user looking at these themes is getting a button that leads them to believe it is not compatible with their OS. To back up the confusion this bug and other changes on AMO is causing users, my theme has seen an 80% drop in downloads between March 25th and 26th (assuming AMO stats are correct). AMO is a live web site and one of the early things many new Firefox users will try. The new site, which is clearly a very buggy beta product SHOULD NOT have been launched before it had time for many of these very easy to detect bugs were worked out. It the new AMO site is too confusing and is misleading users. At the very least it should have been left on its beta domain a little longer with some more publicity being given to the test site for it to have a chance to be more thoroughly tested. It isn't just this bug, it is the scores of AMO bugs and broken/confusing features it contains. The new AMO site is not ready for prime time. In an ecommerce setting where a site like this is mission critical to the business (as AMO should be for Mozilla and Firefox), rolling out such a broken site could have been a firing offense. At the very least the development team would have been raked over the coals. Especially if they weren't getting these types of bugs fixed immediately. Can you imagine if the iTunes site had a bug like this that stopped 80% of its users from downloading songs for this long? Heads would roll I promise you. AMO needs to be reverted to the old site and all of this sloppiness needs to be cleaned up before users are subjected to it and some Mozilla employees should be sacrificing their weekend to fix the mess that was created. If the live AMO site is going to be turned into a test bed, then the AMO developers should have been prepared to fix serious bugs like this within hours (at most a day) of them being reported. There are well paid Mozilla employees at the helm of all of this and Mozilla is raking in millions in Google Ad revenues; we should be able to expect better than what we are seeing now. I am sorry for the rant, but there has been way too much of this kind of frustrating issues for add-on developers with both AMO and Firefox 3.0 beta as of late. I am also not alone on these feelings as the following MozillaZine thread shows: http://forums.mozillazine.org/viewtopic.php?t=642440 Please let's strive to do better. // END VERY FRUSTRATED RANT

Apparently, the "download now" vs. "install now" check changes per-version and not per-button. That of course, labels all buttons the same. I'll look into this and attach a fix. Thanks to everyone for the input you provided.

This patch replaces the per-version code for Download vs. Install with a per-button check, so that subsequent calls to the function do not overwrite other call's changes. Thanks to Chris for unknowingly volunteering for a review.

Comment on attachment 312882 [details] [diff] [review] Changing the install string per button, not per version Changes makes sense to me, tested with MicroHunter variants. One thing: if I'm on a Mac it will show when I look athe version history: Add to Firefox(Windows), Add to Firefox(Linux). Maybe it should say Download Now (Windows Version) Download Now (Linux Version)?

(In reply to comment #7) > (From update of attachment 312882 [details] [diff] [review]) > One thing: if I'm > on a Mac it will show when I look athe version history: Add to > Firefox(Windows), Add to Firefox(Linux). Maybe it should say Download Now > (Windows Version) Download Now (Linux Version)? That's true, that may make sense to avoid installation on the version history page altogether and just make everything download there, in order to make this the central fallback repository for incompatible/old and similar add-on versions. Do you want to file a new bug for this, please?

I committed this to r11835. Thanks, everybody.

(In reply to comment #8) > (In reply to comment #7) > > (From update of attachment 312882 [details] [diff] [review] [details]) > > One thing: if I'm > > on a Mac it will show when I look athe version history: Add to > > Firefox(Windows), Add to Firefox(Linux). Maybe it should say Download Now > > (Windows Version) Download Now (Linux Version)? > > That's true, that may make sense to avoid installation on the version history > page altogether and just make everything download there, in order to make this > the central fallback repository for incompatible/old and similar add-on > versions. Do you want to file a new bug for this, please? I spun-off bug 426953 for this.

I've verified this as FIXED on preview; I also double-checked that bug 427140 is fixed there, and it is. Note that I ran into bug 426793 (preview hasn't yet updated, it seems), but I'll also test the Version History pages heavily when that's visible on preview.