Closed
Bug 538486
Opened 15 years ago
Closed 12 years ago
First Run pages for old Firefox versions should warn user about being out-of-date
Categories
(www.mozilla.org :: General, defect)
www.mozilla.org
General
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: Dolske, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
If a user installs an old version of Firefox, we should show them a First Run page that warn them they're not up-to-date. Currently we don't.
For example, running Firefox 3.0.3 with a new profile opens up http://en-us.www.mozilla.com/en-US/firefox/3.0.3/firstrun/ which just tells me "Thanks for downloading the safest, fastest and most customizable version of Firefox yet."
Bug 390332 covered updating the What's New pages (which users see after receiving an update for an existing profile). That seems to have been fixed at some point... Eg, if you're updated to Firefox 3.0.2, you'll get the URL http://www.mozilla.com/en-US/firefox/3.0.2/whatsnew/ and the message "You’re now running Firefox 3.0.2. For security reasons, we recommend downloading the latest and greatest version." (which links to the download page).
I found a number of old bugs for this problem (bug 378944, bug 378945, bug 378482), but this really needs to be handled automatically (ie, generate dynamic content depending on browser version).
Blake recently blogged about this: http://blog.mozilla.com/metrics/2010/01/05/55-of-new-users-install-old-versions-of-firefox/
Comment 1•15 years ago
|
||
Steven, can you look into this? Ideally we could replicate the solution for the outdated versions of What's New.
Assignee: nobody → steven
Comment 2•15 years ago
|
||
Let me know if I understand the issue correctly: Is the solution to update the firstrun pages for older releases to warn that a newer version is available? If 3.0.3 will always hit en-US/firefox/3.0.3/firstrun/ when it is first run, even if a newer version is released, correct?
If so, we shouldn't need browser version detection in the page - we can just update the (CurrentRelease - 1) pages when a new release comes out.
Comment 3•15 years ago
|
||
That's right, we don't need browser detection. We should, however, update all previous First Run pages.
Here's a breakdown of the traffic for each version:
http://blog.mozilla.com/metrics/files/2010/01/35.png
http://farm5.static.flickr.com/4011/4249642896_a7e5af6671_o.png
http://farm5.static.flickr.com/4041/4249642870_e2bb098dd5_o.png
Comment 4•15 years ago
|
||
How should we modify the page to let users know it's not the newest versions (and why that matters)? I can imagine a few options:
1. Replace the entire page with a notice about the new version.
2. Add a box/notification at the top of the page about the new version.
3. Integrate a note/link about the new version into the existing text/layout.
I'd lean towards #1 or #2. Is there any reason we would want to preserve the content of the firstrun page for out-of-date versions?
Reporter | ||
Comment 5•15 years ago
|
||
I'd also suggest something like #1, so that it's easy to just replace previous pages with a stock "out of date" page.
Would this be an automated thing (eg, based on some server-side variable), or will someone have to update the previous version's page manually? If the latter, is there a formal checklist used when updating the web properties for a release?
Comment 6•15 years ago
|
||
Here's a (very) quick mockup of what such a warning page could look like. Wording, style, layout, etc. are all open for criticism.
Comment 7•15 years ago
|
||
Also, is there a way for a page to trigger the "Check for Updates" function in Firefox? Wouldn't that be the best way to update (rather than downloading a new installer)?
Comment 8•15 years ago
|
||
I like the look Steven.
Instead of directing users to the download page, we could encourage them to "Check for updates" through the browser. I'm not sure which is a better experience/more effective. Thoughts?
Reporter | ||
Comment 9•15 years ago
|
||
There isn't any way for pages to trigger the update check in the browser.
The UX is probably better if they use the browser's update mechanism (vs linking to the download page). The instructions may be a wee bit longer, but there's less risk that we'll leave the user lost and wondering what to do next (like forgetting to actually run the new installer).
Oh, I suppose there's an interesting edge case here (which might be best to deal with later / separately)... Consider a user who installs the last Firefox 2 release, but is on a platform which isn't supported by Firefox 3+. Ideally we'd point such users at a special page for their situation (eg, explaining why we dropped support and recommending they upgrade to an modern release of their OS).
Reporter | ||
Comment 10•15 years ago
|
||
(In reply to comment #5)
> Would this be an automated thing (eg, based on some server-side variable), or
> will someone have to update the previous version's page manually? If the
> latter, is there a formal checklist used when updating the web properties for a
> release?
Beltzner says there doesn't seem to be any such checklist used, so it would be best if we can automate this server-side. Bug 390332 comment 15 implies this was possible at one time...
Comment 11•15 years ago
|
||
Dumb question...
If a user is on 3.0.10 and they click on "Help" -> "Check for Updates", what version do they actually get upgraded to? If the answer is 3.0.latest, then the browser's update mechanism probably isn't the best solution.
Ken: they go from 3.0.10 -> 3.0.17 -> 3.5.7 (manual steps all the way).
Comment 13•15 years ago
|
||
We may have to improve the existing firstrun pages given that this is issue is already out in the install base. However, isn't this something that should be ultimately fixed in by having the installer (or app on first-run) check to make sure it is the latest version? Is there a bug for that?
Comment 14•15 years ago
|
||
(In reply to comment #6)
> Created an attachment (id=421819) [details]
> Initial mockup of out-of-date firstrun page
>
> Here's a (very) quick mockup of what such a warning page could look like.
> Wording, style, layout, etc. are all open for criticism.
Thanks Steven. This looks good, although I do have a few suggestions...how about this:
You're almost there!
Thanks for downloading Firefox, but this version is out of date. For the latest security, performance and feature enhancements we strongly recommend that you _get the newest version_ instead.
[then, where the "get the latest version..." text is now I'd put a green download button instead]
Thoughts? Should we make the copy a bit scarier ("this is an unsupported version", etc) for people who download Fx 3.0.x?
Comment 15•15 years ago
|
||
I've taken John's changes from comment #14 and setup a page in trunk (r60271):
http://www-trunk.stage.mozilla.com/en-US/firefox/out-of-date/
We could redirect previous firstrun pages to this new page.
Comment 16•15 years ago
|
||
Looks good to me. Justin, Blake...what do you guys think?
Comment 17•15 years ago
|
||
Looks good. Maybe (later) we should add a survey to see why users are running old fx versions.
Reporter | ||
Comment 18•15 years ago
|
||
WFM. Nice.
Comment 19•15 years ago
|
||
Any thoughts on how best to implement this? A few options:
1. Remove all first-run pages from previous releases and add redirects to this one page
2. Replace all first-run pages from previous releases with a copy of this page
What about l10n versions? Might it make sense to build something into the firstrun pages that checks the product-details library to see if there is a newer version available for that locale?
Comment 20•15 years ago
|
||
Let's replace pervious versions with a copy of this page. This will make our analysis a bit simpler.
Comment 21•15 years ago
|
||
I'm all for cutting down the number of duplicate pages in the tree. Can we use rewrite rules to get the same effect?
Comment 22•15 years ago
|
||
Would it be possible to do a redirect that appended URL variables that indicated the version?
For example:
redirect: /en-US/firefox/3.0.1/firstrun/
to: /en-US/firefox/outofdate/?v=3.0.1
Comment 23•15 years ago
|
||
(In reply to comment #22)
> Would it be possible to do a redirect that appended URL variables that
> indicated the version?
>
> For example:
>
> redirect: /en-US/firefox/3.0.1/firstrun/
> to: /en-US/firefox/outofdate/?v=3.0.1
yes
Comment 24•15 years ago
|
||
(In reply to comment #23)
> > redirect: /en-US/firefox/3.0.1/firstrun/
> > to: /en-US/firefox/outofdate/?v=3.0.1
> yes
Blake: would this give you what you need for analysis?
Comment 25•15 years ago
|
||
It would, but we'd have to set up a custom campaign for each version. I suppose that's simpler than updating 30+ pages, however. Let's do the redirect.
Comment 26•15 years ago
|
||
(In reply to comment #25)
> It would, but we'd have to set up a custom campaign for each version. I suppose
> that's simpler than updating 30+ pages, however. Let's do the redirect.
Really? Is there another parameter we could add that would tie it together?
Comment 27•15 years ago
|
||
Yeah, I think there's a way to set this up in Omniture so that we can see the correlation/drill-down reports by whatever comes after the "?" (oremj would know more).
Comment 28•15 years ago
|
||
i misspoke--we do not need a parameter for each version.
Comment 29•15 years ago
|
||
and how about l10n? (see comment #19)
Reporter | ||
Comment 30•15 years ago
|
||
(In reply to comment #22)
> redirect: /en-US/firefox/3.0.1/firstrun/
> to: /en-US/firefox/outofdate/?v=3.0.1
Can we instead redirect to outofdate by default, and have exceptions for the current browser version? Judging from previous history (see comment 0), people will forget to add redirects as new versions are released. But QA will quickly notice this when testing an about-to-be-released new version, and get the redirect updated.
Comment 31•15 years ago
|
||
Is there a way we can do this redirection in .htaccess and not have to manually update the "latest version" number with each release? The product-details PHP lib can tell us the latest version number, but that's not accessible in .htaccess, is it?
Comment 34•14 years ago
|
||
(In reply to comment #30)
> (In reply to comment #22)
>
> > redirect: /en-US/firefox/3.0.1/firstrun/
> > to: /en-US/firefox/outofdate/?v=3.0.1
>
> Can we instead redirect to outofdate by default, and have exceptions for the
> current browser version? Judging from previous history (see comment 0), people
> will forget to add redirects as new versions are released. But QA will quickly
> notice this when testing an about-to-be-released new version, and get the
> redirect updated.
What about redirecting all firstrun requests to a central firstrun page that is smart about whether the redirect came from a current version or not?
Something like this:
redirect: /en-US/firefox/*/firstrun/
to: /en-US/firefox/firstrun/?v=*
Then, in the central en-US/firefox/firstrun/ file, we can check the version number in the URL var against the current version in the product-details lib and either show the current firstrun page contents, or a "your out of date" version.
The main drawback I see to this option is that the visible URL for the current firstrun page will end up changing from /en-US/firefox/3.6.8/firstrun/ to /en-US/firefox/firstrun/?v=3.6.8 and the additional redirects could be a bit of a performance hit.
Thoughts?
Comment 35•14 years ago
|
||
It sounds like user agent changes might be in the works to remove the last digit of the version info so only 3.6 might appear, and/or remove firefox info altogether. if that is happening we need to figure out how to accommodate.
Comment 36•14 years ago
|
||
(In reply to comment #35)
> It sounds like user agent changes might be in the works to remove the last
> digit of the version info so only 3.6 might appear, and/or remove firefox info
> altogether. if that is happening we need to figure out how to accommodate.
Chris, that shouldn't be an issue as we're not checking the user-agent. The whatsnew/firstrun pages URLs are hard-coded somewhere in the browser (with the full version number in the URL) and we check it against the latest release number in the product-details PHP library on mozilla.com.
Updated•14 years ago
|
Assignee: steven → abuchanan
Comment 37•14 years ago
|
||
r71870 on trunk, adds a rewrite rule that shows an out-of-date page for all firstrun versions that are *not* in the list of exceptions.
Some gotchas...
1) it's en-US only right now
2) it doesn't include 3.6* and 4.0*
Beltzner / Slater, should I apply this to old 3.6 versions? Everything < 3.6.8? What about 4.0 betas?
3) I created a rewrite rule that shows the out-of-date page only if the version doesn't match (?:3.6.*|4.*). That means if you're creating a new firstrun page that doesn't match those exceptions, you might be scratching your head wondering why you're getting an out-of-date page. I don't like creating a hidden line in .htaccess like that, but we'll see how it goes.
4) firstrun pages only. old whatsnew pages already do something similar, but with a different page. can we use the same out-of-date page for whatsnew too?
Example links:
http://www-trunk.stage.mozilla.com/en-US/firefox/2.0.0.11/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.0.19/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.5.5/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/
Comment 38•14 years ago
|
||
John, can we use this page for old whatsnew pages too?
e.g.
http://www.mozilla.com/en-US/firefox/2.0/whatsnew
http://www.mozilla.com/en-US//firefox/3.0.14/whatsnew/
http://www.mozilla.com/en-US/firefox/3.5/whatsnew/
Comment 39•14 years ago
|
||
(In reply to comment #38)
> John, can we use this page for old whatsnew pages too?
Definitely! Good call.
Comment 41•14 years ago
|
||
This is on trunk as of r74545 and r74546
Includes firstrun and whatsnew.
Doesn't include 3.6* and 4.0*
Wrote a testcase, it's here,
http://svn.mozilla.org/projects/mozilla.com/trunk/tests/testRewrites.py
def testOutOfDate
Keywords: qawanted
Couldn't test all of them, so did:
http://www-trunk.stage.mozilla.com/en-US/firefox/1.0/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/1.0/whatsnew
http://www-trunk.stage.mozilla.com/en-US/firefox/1.0.1/whatsnew
http://www-trunk.stage.mozilla.com/en-US/firefox/2.0/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/2.0/whatsnew
http://www-trunk.stage.mozilla.com/en-US/firefox/2.0.5/whatsnew
http://www-trunk.stage.mozilla.com/en-US/firefox/3.0.5/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.5/firstrun/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.5/whatsnew
http://www-trunk.stage.mozilla.com/en-US/firefox/3.5.2/firstrun/
Verified FIXED on staging.
Keywords: qawanted → push-needed
Comment 43•14 years ago
|
||
r75795 on production
Comment 44•14 years ago
|
||
verified fixed on production
http://www.mozilla.com/en-US/firefox/3.5.16/firstrun/
http://www.mozilla.com/en-US/firefox/3.5.15/firstrun/
http://www.mozilla.com/en-US/firefox/3.5.10/firstrun/
http://www.mozilla.com/en-US/firefox/1.0/firstrun/
http://www.mozilla.com/en-US/firefox/2.0/firstrun/
Status: RESOLVED → VERIFIED
Comment 45•14 years ago
|
||
FYI, the whatsnew and firstrun pages bypassed by this re-write have been removed in the nova branch (r77401, r77402).
Comment 46•14 years ago
|
||
Reopening, we are still shipping 3.5.x releases. Firstrun and Whatsnew pages for en-US and locales were removed on the nova branch along with 2.0 and 3.0 pages, but not on trunk/production yet for locales.
Is it ok to tell people that will install/update to 3.5.16 this month that their version is out of date?
Beltzner or LegNeato could decide maybe?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Updated•14 years ago
|
Assignee: abuchanan → nobody
Comment 47•14 years ago
|
||
Yeah, this is wrong. I'm pushing the pages for the beta updates now and they redirect to unsupported...I'll try to clean it up with a bandaid
Comment 48•14 years ago
|
||
Ok, I made a special exception for 3.5.19 to unblock the beta push
Assignee | ||
Updated•13 years ago
|
Component: www.mozilla.org/firefox → www.mozilla.org
Updated•12 years ago
|
Status: REOPENED → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•12 years ago
|
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in
before you can comment on or make changes to this bug.
Description
•