handle "your os is not supported on the new version" scenario in the software update UI for fx 1.5 / 2.0, we added code to pass the os version as part of the aus url (bug #341190) and on the aus side, we made it so if for a given os, if the new version was not supported, we could offer an empty update snippet (bug #343689). here's the problem: when firefox 3 comes out, and we offer a major update to fx 2 users, those users on windows 9x will get "no updates available". perhaps we should do this: instead of an empty snippet, a different snippet of a form like: <?xml version="1.0"?> <problems> <problem url="http://www.mozilla.com/en-us/os-is-not-supported.html"> </problems> in the client (on both the trunk and the 2x branch, we would have the update service, upon a "problem", would throw up a simple xul window of the following ui: ++++++++++++++++++++++++++++++++++++++++++++ + Software Update [x] + ++++++++++++++++++++++++++++++++++++++++++++ + There were problems checking for, + + downloading, or installing this update. + + Firefox could not be updated because: + + + ++++++++++++++++++++++++++++++++++++++++++++ + [ xul:browser loaded to + + os-is-not-supported.html ] + + + + + + + + [OK button] + ++++++++++++++++++++++++++++++++++++++++++++ Note these strings are on the 2.x branch already: http://lxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/chrome/mozapps/update/updates.dtd#1 http://lxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/chrome/mozapps/update/updates.dtd#51 So we could do this on the fx 2 branch without adding new strings. For the trunk for firefox 3 -> 4, we could add better strings. Note, we could also use this feature to solve the problem of what do we tell users who can't update because they don't have admin rights to their machine. for non admin users, we would remove the code that stops checking for updates and disables the help | check for updates menu, and we could extend the aus url to include a boolean indicating if they are admin or not. upon update, if they are non admin, instead of doing what we normally do, we'd fix aus to return: <?xml version="1.0"?> <problems> <problem url="http://www.mozilla.com/en-us/you-are-not-admin.html"> </problems> I think this is something we should do for trunk, and then backport to the 2x branch. thoughts / comments?

I think we should only provide this for releases of the application that are no longer supported (e.g. when they reach EOL). I would personally be annoyed if an app took the time to tell me that there is an update available but I can't use it because my OS is not supported. When a release reaches EOL I think it is appropriate to let the user know that future security updates won't be available. Don't forget the OS requirements changed for Mac OS X and Linux.

They changed for Linux, but the old app/AUS whether the system matches the new requirements without running a test program: the problem is that the Linux version (the kernel version) has no bearing on actual compatibility, which is mainly gnome and other system library versions.

I've been thinking that it may be appropriate to use a different message entirely for Linux due to this.

I'm not sure we can block 1.8.1.7 specifically if this isn't done and ready on the trunk by then, although it is definitely wanted before we want to start updating users (would we want to give beta Major Update offers to FF2 users on the beta channel?). But given l10n freeze it pretty much needs to be done by M8 if it's going to make FF3 so maybe that's not going to be a worry. Unless we want to ship a Firefox 1.5.0.14+ with this fix we won't be able to Major Update 1.5 users to FF3. I guess we can assume if they haven't updated to FF2 by that time they aren't likely to make the jump to FF3.

We can't realistically block 1.8.1.7 for this, especially given the localization this will require. Once we've got a design for trunk and have it localized we can talk about when and how to back-port much as we did with the Major Update feature.

If we know the problem when generating the window "os-is-not-supported.html", then why have the vague introduction? + There were problems checking for, + + downloading, or installing this update. + + Firefox could not be updated because: + + + I think we should try to focus on exactly what the issue is. We also need to provide inline directions (or links) to tell them exactly how to resolve the issue. For instance, os-is-not-supported.html needs to include a list of supported operating systems, explain that the options include upgrading your OS, buying a new computer with the OS pre-installed, etc. you-are-not-admin.html needs to explain what an admin account is, and how you would go about accessing one, or getting access to one. Instead of just reporting the error, we need to do everything we can to help the user resolve it. And we really shouldn't just use the usual "contact your IT department" doge which is far too commonly found in error dialogs.

> why have the vague introduction? the vague introduction is for the 2.x branch, where we are string frozen. But the server side is not string frozen, and we could have our error pages be localized. for the trunk (fx 3), we'd add new strings.

>the vague introduction is for the 2.x branch, where we are string frozen. What if we removed the vague introduction and provided all of the error information on the server. If the connection is down, then we could show the vague string.

Need this fixed in Fx2 before Fx3

The "you are not admin" scenario is covered by Bug 407875

Can we have some traction on this, please? This is leaving users with known security holes, without us even notifying them. That's badly neglecting (under some jurisdictions, the software publisher may even be liable, despite all disclaimers, because you're not warning about a *known* problem). With macosx 32bit dropping, this is going to affect a lot of people. At the least, they must *know* about the problem they have, and they should be urged to act. The message should say that a) there are no more updates for him b) there are *known* security bugs, and he *must* act ("You are driving without brakes") c) offer suggestions what he can do (if any) This is trivial to implement, it's just a dialog box.

I won't have time to look at this in the immediate future due to other work that takes priority.

Forgot this was already filed. This was taken care of in bug 843497.