User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008032705 Minefield/3.0pre Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008032705 Minefield/3.0pre Firefox/3.0 ID:2008032705 The new version of addons.mozilla.org (amo) is no long user-friendly for advanced users and users of multiple versions of Firefox. amo should NOT outright block the downloading or installation of add-ons considered "incompatible." Many add-ons are incompatible only because the information in install.rdf is not "current" or the add-on author has not tested their add-on in a specific version. Rather than blocking downloading or installations, users should only be warned that the add-on they are viewing or installing may not be compatible and that use is done "at the user's risk." This also makes advanced users have to switch between different versions of their browsers to access "version-compatible" add-ons. Previously, I could download any and all add-ons I needed and then install to any and all of my installed Firefox 2/Trunk/Beta versions whenever to individual profiles or globally as I do for Firefox 2. Reproducible: Always Steps to Reproduce: 1. [Example} Using Trunk, find an add-on that is not compatible with Trunk. 2. Try to install or download incompatible add-on. Actual Results: User cannot install or download the incompatible add-on. Expected Results: User should be able to install or download an incompatible add-on after confirming that they understand the add-on is incompatible and assuming the risk of using an incompatible add-on.

There is a way to do this at the moment. If you expand the "Advanced Details" section, you can click on "Complete Version History" and download/install whichever versions you like.

The expand "advanced details" link is not at all obvious. It would be much better to either expand out advanced details by default or to put the "complete version history" link in a different place. Also when I looked at my theme only one OS version of the theme was being made available to me even on the "complete version history" page even though the latest version of my theme has different OS versions for Linux, Windows and Mac.

Though it may be "available," users should not have to use an unapparent "work-around" to install or download incompatible add-ons. (In reply to comment #1) > There is a way to do this at the moment. If you expand the "Advanced Details" > section, you can click on "Complete Version History" and download/install > whichever versions you like. >

That is because the new AMO is reading the browser you are accessing it with. Again, the new AMO makes it painful and inconvenient to access/download incompatible add-ons. That is the opposite of being genuinely "user-friendly." (In reply to comment #2) > Also when I looked at my theme only one OS version of the theme was being made > available to me even on the "complete version history" page even though the > latest version of my theme has different OS versions for Linux, Windows and > Mac. >

Between the new default theme on Windows Firefox and issues like this on the new AMO, I'm starting to feel like a usability nag. I'm really starting to get keyboard key indentations on my forehead. It really does not feel that solid thought is being put into usability on either front. This bug is an example of that. (In reply to comment #4) > That is the opposite of being genuinely "user-friendly." >

How about a user preference that acts like "extensions.checkCompatibility" in Firefox? Advanced users could turn this setting on to allow them to install any add-on they want without the compatibility checks getting in the way...

I really don't see the need for this option. The old way worked just fine. The main page for an add-on displayed one link for the compatible version of an add-on based on UA string and the "complete version history" showed all versions (hence the word "complete"). Showing only add-ons for the "detected" OS in the "complete version history" isn't a complete version history, thus the title is misleading.

A site preference might be a better way to go. We "advanced users" probably have registered on AMO. In settings, we can tell AMO to disregard the specific browser we are using to access it. In addition, include the ability to search for add-ons based in part on which versions of browser the add-ons may be compatible with. I think that is a bug that has been filed for some time now, too. (In reply to comment #6) > How about a user preference that acts like "extensions.checkCompatibility" in > Firefox? Advanced users could turn this setting on to allow them to install any > add-on they want without the compatibility checks getting in the way... >

An account option really sounds like the best idea to me. In fact, we should also have an account option to outright hide incompatible add-ons. There's a couple pages in some of the lists that'll have half listed as incompatible due to my OS or FF version. Sadly, with the release of Firefox 3 I expect that many old extensions just may not ever be updated and they should be hidden or pruned off altogether.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=425382

Adjusting the summary to better reflect what's this bug about right now.

It is also impossible to download an extension which is not compatible with our OS, even via Version history. I think an account option is not a really good idea, as most of the people should be using AMO without being logged in when they don't need it (eg. for using Developer tools or Sandbox), due to bug https://bugzilla.mozilla.org/show_bug.cgi?id=374978 (AMO should offer "Remember Login" when logging in). The button already is in gray and there is an alert. If the user still wants to install the extension, he will be notified that it is incompatible par the application. This should be enough.

At the most, users should be prompted to confirm that they are installing an add-on that may be incompatible with the browser they are using and do so at their own risk.

I agree with Nicolas (comment #13) and Ray (comment #14), users should be able to download what ever add-on they want. An extra warning prompt should be more than sufficient. There are many very legitimate reasons for wanting to download a version of an add-on that might not be compatible with the system the individual is on.

But by default, the extension won't install anyways because by default 'extensions.checkCompatibility' is set to true. Well it actually has to be manually added but you all know what I mean. So why even let the user download the extension if it won't install anyways without them having to add a about:config entry? This will just leave it open for users to install incompatible extension and cause more headaches for support people.

Here are some common reasons to allow the download: -Developer wants to download say a theme from an OS other than their own to see how something is done in that OS (I've done this many times). -An IT department supports multiple OSes and want to install specific add-ons on all computers on their network from a central point. Not allowing add-ons for different OSes to be downloaded would force one to use different machines or come up with some other work around. -Add-on developer may upload different JAR files for say Windows, Mac and Linux because this is what they tested on. However, the Linux version would also work on other Unix variants (e.g. FreeBSD). As things stand now the FreeBSD user would be denied the ability to download an add-on that would work just fine for them but the developer didn't flag the add-on correctly. -A version bump to Firefox makes an add-on to appear to not be compatible simply because it contains the wrong max version information. All that is really needed is for the user to crack open the add-on and fix the max version information or to use some other means of overriding the max version declaration contained within the add-on. -The user should have the right to sow the seeds of their own demise. Firefox is supposed to be about user choice and part of this includes being able to download what ever add-ons they want even if the add-on might not be compatible with their system.

Related and important too: bug 425539 (Bring back the compatibility ranges).

Incompatible add-ons can also be "enabled" by use of the Nightly Tester Tools and MR Tech Toolkit (formerly Local Install) add-ons. My primary objection is this notion on the part of the programmers of AMO 3.2 that users are incompetent fools who need to be protected from themselves. Thus, they code AMO 3.2 to never allow anyone to even assume the risk and try an add-on that may or may not work with the version of browser being used at that moment. Interestingly, over half of my nearly 40 installed add-ons are incompatible with Minefield, yet, I have only one out of all of those, that I have determined caused Minefield to crash. Ironically, that one add-on's previous version did not cause Minefield to crash. Hhhhmmm. Based on my experience, the programmers of AMO created a solution for a problem that did not really exist. They wasted time doing that coding and still no one as addressed the inability of registered users to change their email addresses. If I was heading this project, my question to the programmers is "Why did you spend all that time on blocking access to incompatible add-ons when registered users still cannot change their email addresses, an issue that has been known for quite some time?" (In reply to comment #16) > But by default, the extension won't install anyways because by default > 'extensions.checkCompatibility' is set to true. Well it actually has to be > manually added but you all know what I mean. So why even let the user download > the extension if it won't install anyways without them having to add a > about:config entry? > > This will just leave it open for users to install incompatible extension and > cause more headaches for support people. >

so um, you as a single user may have only hit one crash. but we have to deal w/ hundreds of users experiencing crashes. and they on average don't realize that it's an extension's fault. so they blame us. fwiw, i have no real opinion on this bug.

(In reply to comment #19) > My primary objection is this notion on the part of the programmers of AMO 3.2 > that users are incompetent fools who need to be protected from themselves. Have you ever ventured into the support forums on mozillazine or been on sumo? I'm not saying that the users are incompetent but are not as advanced as the power users to understand that bumping version numbers to install extension that have not been tested and certified (as in the extension author saying it is compatible for a certain extension) are not the fault of Firefox but the user themselves. No matter what, Firefox is the problem in their eyes. In some ways they are correct, in certain instances like an extension should never crash the browser but that is a different topic. It should not be allowed for any user to install any extension they want to advoid the problems as described in my posts and others in this bug report. If it was the case why have a black list, why have min(max)Version in the install.rdf, why have OS specific code in extensions...etc etc. This is to help advoid problems that grandma may encounter by just installing anything that is out there.

IMHO, AMO should offer to non-logged users AUTHORIZED and NON-AMBIGUOUS actions only, which means download something that will actually 1) be installed in Firefox and 2) will work without bugs (I mean, being compatible with the version of Firefox). My Grandma should no never be bothered and worried by some warning message explaining that "this extension might not be compatible. Do you want to proceed?" As simple as that.... Now, how can we do for the *small* (compared to the Firefox user base) crowd of people like us, who are currently reading this screen? I see 2 directions: - either require such advanced user to be logged in on AMO in order to download extensions beyond the version boundaries - or having an Firefox option or better, an official extension like "Nightly Tester Tools" that would "talk" to AMO when viewing an extension in order to unlock the download of any version, and eventually would also allow the installation of the downloaded extension in Firefox, thus killing 2 birds with 1 stone. As a matter of fact, I prefer the latter option (extension), as it would keep the Firefox options simple. I really think that we, developers and testers, could live with such a principle. At least, I could.

Klint (comment #22) makes sense in regards to protecting the masses while giving the minority the flexibility they need. Requiring an AMO account with a setting in the developer's area to enable/disable the download of incompatible add-ons would more than suffice to address the needs of both groups.

A few of the comments in this discussion are missing the issue here. Yes, users shouldn't be able to install incompatible extensions. (unless they deliberately and knowingly use something like Nightly Tester Tools to hack it) That is a browser-related issue; this is a discussion about AMO. Users should be able to _download_ anything they want, even if the browser they used to view AMO won't install it. Just put an extra layer of consent on things in the form of requiring a login and selected option, and call it a day.

I'm all for the most freedom of our users. We should allow them to download whatever addons they want. But for not-so-technical users we should at least provide some messaging/features that will let them know immediately that an addon is incompatible. I like the idea of a link to the complete version history. It could be put somewhere (hopefully) near the install button. We shouldn't require creating an account to download addons, every time I have to do it for other software, it bugs the hell out of me :)

We're having a problem because we have to cater to two very different user audiences here, as a couple of people have pointed out so far. First, there's the huge population of casual users who would be surprised and annoyed to find that we're even offering add-ons that aren't compatible with their browsers. Letting them download add-ons that we know won't work, even (especially?) if we tell them that it won't work after they've spent the effort to do so, doesn't respect their time. Second, there's the comparatively small but important set of users who have reasons to download incompatible add-ons, whether because they're developers, early (pre-release) adopters, or because they're installing them somewhere else (i.e. as an IT person). We've been designing for the first group on purpose, partly because there are so many of them, but also because they're the group that is less likely to figure it out on their own. We have more responsibility to guide them through the process successfully than for the latter group. For that reason, I'd disagree with adding complications to the "Add to ..." button areas (with the possible exception of doing so when the user is logged in). That said, though, we can certainly make it easier to find the full list that it is right now. For starters, we can make a link to the Version History page more prominent, and/or give it a better name, and make other OS versions available there.

(In reply to comment #26) > For starters, we can make a link to the Version History page > more prominent, and/or give it a better name, and make other OS versions > available there. On a very short side note, when the already committed fix to bug 426003 goes online, the other OS versions will show up there as expected.

(In reply to comment #26) > First, there's the huge population of casual users who would be surprised and > annoyed to find that we're even offering add-ons that aren't compatible with > their browsers. Letting them download add-ons that we know won't work, even > (especially?) if we tell them that it won't work after they've spent the effort > to do so, doesn't respect their time. That's why we shouldn't even be _showing_ the incompatible add-ons. We really should have them hidden by default and require toggling a checkbox to even list them. (like for sandboxed; and both should hide by default, by the way, unlike the current live version)

It feels like we can solve most of this problem by making the link more prominent in it's positioning (at the moment it's the last thing on the page, within a collapsed box), more visually findable (currently, it's just a regular text link), and giving it a name that will better convey that it's not just about old versions but about all versions (including other platforms)? See the attached image for what I mean. Alongside this, we should improve the design of the All Versions page -- listing which versions of the app each old version is compatible with, for example. And also providing buttons, for each version, for each of the platforms it's available for.

It is maybe possible to have at least a download (and not install - as for Thunderbird extensions) link? It could be a simple link under the gray Add to Firefox button.

(In reply to comment #30) > It is maybe possible to have at least a download (and not install - as for > Thunderbird extensions) link? > > It could be a simple link under the gray Add to Firefox button. If it required setting some account option to see, then yes. However, if you're talking about how to do it by default for everyone, then I'd have to disagree. Inexperienced users shouldn't even be aware that you can get incompatible extensions, as they're the ones we don't want to try to install them. Besides, the only difference between "download" or "install" is if Firefox decides to open the file or save it somewhere. The saved file can then just be dragged over and installed.

This is my patch for the solution suggested by madhava in comment 29. It makes the "all versions" link much more prominent by putting it in the top part of the details page.

"See all versions" seems like something I would click if I wanted to get a different version than the one on the front page. It doesn't convey that you'll able to bypass the compatibility check. I still don't think it's good enough, we need something more to the point.

Some further development on this theme in bug 425539. Also, Fred, could you attach a screenshot of the fix in comment 32?

Madhava: This is a partial screenshot of the fix in attachment 314297 [details] [diff] [review].

What you've got works as advertised (so, r+), however, I agree with Adam. It feels like we should put a link right next to the install button that says something short and useful. If we don't want a visible link (which I think I'm supporting right now), we could do something like the javascript popup on facebook.com when you click the "Remember me" box right before you log in. We could do that on mouseover a disabled button and have the box say something informative and provide a link.

(In reply to comment #36) > If we don't want a visible link (which I think I'm supporting right now), we > could do something like the javascript popup on facebook.com when you click the > "Remember me" box right before you log in. We could do that on mouseover a > disabled button and have the box say something informative and provide a link. I like this idea (morgamic already made this suggestion to me earlier, but I wanted to get the "more prominent" patch in first). In order to see what this could look like, maybe Madhava could even mock something up? (hint, hint)

(In reply to comment #36) > What you've got works as advertised (so, r+)... I committed it to SVN, r12084.

Related to this bug, the maximum version of any add-on that is compatible with the users version of Firefox needs to be offered to them instead of giving them a grayed out download box. This will help reduce user frustration during periods of major browser transition like we are going through with Firefox 3.0.

OK. How about this: 1. Have the "See all versions >" link as proposed earlier 2. Include the compatibility range, as in bug 425539 I've attached a mockup of what 1 & 2 would look like. 3. When a user is logged in, under the assumption that this is a good way to reach advanced users only, we can put a link in the box around a disabled install button. We already provide a link to older add-on versions when the browser they're using is older than the current version of the add-on, so we only need to add this link in the "This add-on is for older versions of Firefox" cases. How about, under the disabled button, adding the following link to the all versions page: "Install add-on anyway." Again - this is only if the user is logged in.

I like all of your suggestions, Madhava, but I dislike the wording for the "install anyway" text, because for semi-advanced users (who understand a lot but who don't have the Firefox about:config flag set that allows installing incompatible add-ons), they will click on install, just to find out that it *still* won't install, since Firefox will complain. I think we need wording that does not suggest you can "install it anyway", but that suggests that you can find the file download anyway if you need it.

Maybe the simplest solution is the best: How about "Download it anyway"?

Thank you for the mockup Madhava, but maybe I missed something on the logged in case. If the link is to the "All versions" page it should not be titled "download it anyway" or "install add-on anyway" because that would imply this particular link will let you download or install it. Perhaps it can say something like "Access all available versions" or something tighter. "Download" or "Install" imply that the link is the .xpi

possibilities: - Get any version - Get it anyway - Install any version (doesn't imply immediate xpi install in the same way) - Download any version I think the second to last is my preference.

Good point Basil. In regards to the older add-on versions link for users of older versions of Firefox, from what I have observed, it is only available when users are logged in. What is needed is a link to the correct older version of an add-on for users of older versions of Firefox without users needing to be logged in.

(In reply to comment #45) > In regards to the older add-on versions link for users of older versions of > Firefox, from what I have observed, it is only available when users are logged > in. No, this is not true. Logging in is not needed to access older versions. If for some reason it is, that'd be a bug... > What is needed is a link to the correct older version of an add-on for > users of older versions of Firefox without users needing to be logged in. This would be overkill, I think. I don't think we should encourage installing older versions more than necessary.

(In reply to comment #46) > No, this is not true. Logging in is not needed to access older versions. > If for some reason it is, that'd be a bug... You are correct. I think I'm flipping back and forth between FF2 and FF3 so much that I'm getting confused by what I see where and when. > > What is needed is a link to the correct older version of an add-on for > > users of older versions of Firefox without users needing to be logged in. > > This would be overkill, I think. I don't think we should encourage installing > older versions more than necessary. When it comes to the time period during major version changes for Firefox where the new version is in beta, I disagree. In many cases the only reason for the new add-on version is to support the new Firefox, but it may be impractical to support the old version of Firefox with the new add-on version (e.g. as is the case with themes). Beta versions of Firefox are not really supposed to be for general public consumption, but at the same time, we want to get add-ons updated and ready for the new version of Firefox and support FF beta users as much as possible. If the only reason for the new version of an add-on is to support the new version of Firefox then during the beta phase, then users of the current release version of Firefox (e.g. FF2 right now) should be offered the compatible version of the add-on.

(In reply to comment #44) > possibilities: > > - Get any version > - Get it anyway > - Install any version (doesn't imply immediate xpi install in the same way) > - Download any version > > I think the second to last is my preference. Yeah, I guess we could give that wording a shot, but I am not too confident that this won't spawn feedback along the lines of "I tried to install a version off the all versions page and Firefox didn't let me". But since we will be showing the text for logged in users only, we should probably be fine. I'll make a patch for it.

I would also like to make a note that the recent changes to addons.mozilla.com also makes it impossible to tell which extension or compatible with a specific version of Firefox. If the user wanted to install the a beta or version from an earlier branch (like 1.5), they could not see if they will loose any of their extensions by browsing the addons site.

(In reply to comment #49) > I would also like to make a note that the recent changes to addons.mozilla.com > also makes it impossible to tell which extension or compatible with a specific > version of Firefox. That's a different bug: bug 425539.

This patch adds an "install any version" link below the "incompatible" install button, for logged-in users only. Wil, please review.

Madhava: This is a screenshot of the patch in attachment 315091 [details] [diff] [review]. Is that okay? Again: This is for logged-in users only, anonymous visitors do not get the "install any version" link.

Is there a bug for keeping users logged in on AMO? We should not have to keep logging in each time we visit AMO.

(In reply to comment #53) > Is there a bug for keeping users logged in on AMO? We should not have to keep > logging in each time we visit AMO. Yes, that's bug 374978. Please use bugzilla's search function for questions like this or step by #amo on the Mozilla IRC server. We should keep this bug from getting longer and longer by staying on topic.

Fred - at some point in the future, I'd like to better center the text and button, but, in terms of getting the link in, this is great.

Comment on attachment 315091 [details] [diff] [review] "Install any version" link for logged-in users I'm r-'ing the patch because the link goes to: /en-US/firefox/addon/addons/versions/$addonid for me which is a 404. (Too many "addon"s in the URL). I'm also unsure about the wording of the link. When I read the link (and this is the FF3 use case right now), I see: This add-on is for older versions of Firefox [Install any version] That looks like it's suggesting I install another version of Firefox. I prefer "Get it anyway" or "Ignore this check" and instead of going to the older versions page, why not just enable the download button via javascript?

Madhava: What do you say to the wording of the link? I can understand Wil's reasoning. "Ignore this check" plus enabling the button would work for me, considering the whole *disabling* happens via Javascript as well, so people with JS disabled won't see the whole deal anyway. (We may need to figure out where to store the data when we disable stuff, so we can re-enable it later, but that's a different story).

Another, I hope quite unambiguous, wording suggestion would be "show install button anyway".

How about "Ignore version check" ?

Yes, that would work well. I'll attach a new patch shortly.

This patch adds an "Ignore version check" link that re-enables the install button, all in Javascript. This is noscript-safe because the whole check is added in JavaScript only anyway, so the restore button will only be seen in case of JS enabled. Wil, please review.

Comment on attachment 315615 [details] [diff] [review] "Ignore version check" link Much better, thanks. Can you also add an @partial English fallback since this is going live in just a couple days with no warning for localizers?

(In reply to comment #63) > Can you also add an @partial English fallback since this is going live in just > a couple days with no warning for localizers? Absolutely. I added translation fallback and checked this in to SVN r12237. It'll go online with the 3.2.1 push which is planned tomorrow. Thanks, everybody.

Screenshot for the curious.

Verified FIXED on http://remora-trunk.php5stage.mozilla.com/en-US/firefox. Looked for fallout (expecting none, of course! :-P), and couldn't find any; JavaScript-disabled case still displays its "Download Now" button (etc.) Tested: 1) search-results pages (http://remora-trunk.php5stage.mozilla.com/en-US/firefox/search?q=foxytunes&cat=all) 2) add-on details pages (http://remora-trunk.php5stage.mozilla.com/en-US/firefox/addon/219) 3) category-landing pages (http://remora-trunk.php5stage.mozilla.com/en-US/firefox/browse/type:1/cat:38)

Why 'push-needed' keyword was removed? For what I see the patch is not already pushed to addons.mozilla.org

This was pushed several weeks ago on May 1.

It strange. I can't see the "Ignore version check" link. Only "See all versions" links work. An example: https://addons.mozilla.org/firefox/addon/5485/

Lucas: Are you logged in? See comment 40 (for example).

(In reply to comment #70) > Lucas: Are you logged in? See comment 40 (for example). So I must be logged in. I tested and it works. But it's extremely useless. addons.mozilla.org requires login for every session, so I must login every time to download an incompatible add-on? At that point, for an "advanced user" is more simple to disable Javascript for addons.mozilla.org, as I did previously. addons.mozilla.org should create a login cookie, and should show the link even if you are not logged in, if extensions.checkCompatibility is set to 'false'. I think I'll create two enhancement bugs for these two problems.

(In reply to comment #71) > (In reply to comment #70) > > Lucas: Are you logged in? See comment 40 (for example). > > So I must be logged in. I tested and it works. But it's extremely useless. > > addons.mozilla.org requires login for every session, so I must login every time > to download an incompatible add-on? At that point, for an "advanced user" is > more simple to disable Javascript for addons.mozilla.org, as I did previously. > > addons.mozilla.org should create a login cookie, and should show the link even > if you are not logged in, if extensions.checkCompatibility is set to 'false'. > I think I'll create two enhancement bugs for these two problems. > Bug 374978 - AMO should offer "Remember Login" when logging in has been filed for some time now.