Closed Bug 1150173 Opened 9 years ago Closed 9 years ago

en-US/plugincheck/ says "Update your Firefox". Help->About Firefox says "Firefox is up to date"

Categories

(Plugin Check Graveyard :: General, defect)

Other
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: edburns, Unassigned)

Details

I visited en-US/plugincheck/ and it says "Update your Firefox".  I went to Help->About Firefox, and it says, 36.0.4 "Firefox is up to date".  Who is right?
Something is broken in the updater for Firefox and Thunderbird. Both have a new version available but "help > about" does not show the new version. Also automatic update does not trigger.
It could also be that one of the mirrors is out of synch.
(In reply to edburns from comment #0)
> I visited en-US/plugincheck/ and it says "Update your Firefox". 
> I went to Help->About Firefox, and it says, 36.0.4 "Firefox is up to date".
> Who is right?

On Tuesday 2015-03-31 at about 19:00 BST (18:00 UCT)
I also I went to Help->About Firefox.
  Using Fx 36.0.4 (en-GB)
    (that I had started with Windows Administrator privileges;
    my 'normal Users' can not Update Firefox [or other software]).

As I expected, Fx 36.0.4 Updated to Fx 37.

> Who is right?
In this case Plugincheck is correct, Fx 37 was released on 2015-03-31.

However, since then Fx 37 has been pulled.

As a result you will see:
> Help->About Firefox, and it says, 36.0.4 "Firefox is up to date".

See the 'sticky' post:
"SUMO community discussions
  Firefox 37 Release / Issues / Status"
https://support.mozilla.org/en-US/forums/contributors/711208?last=64767

and
"FF 36.0.4 will not automatically update to 37"
http://forums.mozillazine.org/viewtopic.php?f=38&t=2925341

My advice is to try "Help->About Firefox" again, once per day.
I expect that a Fx 37.0.1 will be released soon.

edburns,
when you have a Fx 37.0.1
please can you report here in this bug and then close it.

DJ-Leith
CCing Kohei Yoshino [:kohei], who fixed
bug 1128885 "Plugincheck-site considers 31.4.0ESR out of date"
(and Duplicates / similar, e.g. bug 1125166)

and Schalk Neethling [:espressive], who works on Plugincheck.

Kohei,

This bug is about / brings to light,
(I am using single quotes for slang / imprecise language
and double quotes for direct quotations),
'What happens when there is a chem spill of Release?'.

Presuppositions:

Presupposition 1.
The definitive way to test 'Is my Firefox Up to Date?' is to do
Help->About Firefox (as edburns, the OP did, in comment # 0).

Firefox (including Nightly, DevEd [AKA Aurora] etc) then checks
to see if there is a 'newer version'.
If there is, then do an Update.
  In my case, (comment # 3) which is similar to ESR - where I only
  allow Users who have Administrator privileges to 'Update any software',
  I see "Updates available at https://www.mozilla.org/firefox/"
  when I test 'an old Release' using "Help->About Firefox".

Presupposition 2.
A secondary way to help Users to keep their Firefox current
is to 'detect old versions' as they visit mozilla.org
(either when they visit by 'direct browsing' or
'incidentally as they are doing a Plugincheck' - as happened in this bug).

If 'old versions of Firefox are detected' visitors are shown
"Looks like you’re using an older version of Firefox."
and a button to
"Update your Firefox".
This is done by checking the User Agent.
IIUC, in the case of ESR an additional check is done using "navigator.buildID".


Time-line, for the recent Fx 37 chem spill (Fx 36 had several!):

2015-03-31 Fx 37.0 is Released.
  I and others update Fx 36.0.4 to Fx 37.0.
  Then Fx 37 is pulled for a chem spill.
    Reasons include crashes (bug 1149761)
    and security issues see
    https://www.mozilla.org/en-US/firefox/37.0.1/releasenotes/
  While the chem spill is being worked on
  Help->About Firefox, for Fx 36.0.4, says "Firefox is up to date"
  because there was 'no Release version available' and,
  IIUC from reading this bug,
  a Plugincheck showed the "Update your Firefox" button
  because the UA was 'old Firefox - in this case Fx 36'.

2015-04-03 Fx 37.0.1 is Released.

Three points:

1. Is is desirable, when there is a chem spill, to try and
'keep in step with the chem spill'
and NOT show the "Update your Firefox" button
WHILE there is 'no version of Release available'?
This might be 'too much work'?

2. Consider the case of Users who have Fx 37.0.
They should, for safety, be shown the "Update your Firefox" button
now that Fx 37.0.1 is available.
  Testing, today, with Fx 37.0
  I am NOT shown the "Update your Firefox" button when doing a Plugincheck.

3. If it is desirable to do either 1 and/or 2,
could you use the same method as the ESR case
(i.e. test both UA and buildID) to give 'best advice'?

DJ-Leith
Let me check what's happening here.
Flags: needinfo?(kohei.yoshino)
As more of Plugincheck is moving into Bedrock,
and is, temporarily - in the first instance,
only going to be used to 'test plugins in Firefox'
(see bug 1121456 "PluginCheck for Firefox").

Two additional points:

1. How old is 'too old': when to interrupt a Plugincheck.

In bug 1088212 "Modify out-of-date Firefox redirect on /whatsnew & /firstrun"
there was a discussion about, I paraphrase,
'how to decide (and test for) an old Firefox visitor' and when to REDIRECT them.

The idea was to 'NOT redirect too soon', but wait until the version was
more than 2 versions old before redirecting.

In that bug there is data, from Google Analytics, about number of visitors.

In a 'Plugincheck test' users are wanting to 'check their plugins'.
They don't want to be 'told their Firefox is old' - too soon.

  Also, they do not want to be redirected away from Plugincheck.

So, IMO, showing a message:
"Looks like you’re using an older version of Firefox."
and a button to
"Update your Firefox".
To Fx 36 (and older - 1 version old)
but NOT to Fx 37.0 (even after Fx 37.0.1 has been released)
is the 'right balance'.

The Plugincheck is 'still done' (it is not interrupted / redirected)
and the plugins are reported, with the "Update your Firefox" button
at the top of the page, in Fx 36.


2. How to detect browsers for Plugincheck.

See bug 1153588 "Plugin check service stopped working for SeaMonkey"

Philip Chee makes an excellent point:
> SeaMonkey is a mozilla based browser and has the same plugin architecture
> as Firefox. Hence there is no reason to block SeaMonkey.
> 
> If I change the navigator.userAgent from:
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 SeaMonkey/2.37a1
> to
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
> 
> The plugin check service works nicely with SeaMonkey. Please change your
> UA sniffing code to allow SeaMonkey to use the plugin check service.

It would be very good if the 'test of the browser for Plugincheck'
allowed SeaMonkey.

DJ-Leith
Sorry I'm late. The bugs I have fixed before were related to Firefox 31 ESR (https://www.mozilla.org/firefox/organizations/) and not relevant to the issue reported here. ESR is difficult to handle because we don't have any reliable way to distinguish the ESR and old non-ESR Firefox 31 users. 

Basically, both the Web site (more precisely, dataset behind the site called product-details: http://viewvc.svn.mozilla.org/vc/libs/product-details/?date=week&view=query) and Firefox download servers are being updated manually and separately by the Release Engineering team, so there could be some time lag for now.

As far as I know, the team is working on a new automation tool called Ship-It (Bug 1083718) and once it's deployed, the lag will be *almost* gone. Because the site is automatically updated every half hour or so, there will still be a short time lag, but it should probably be acceptable.

I'm closing this bug, but feel free to reopen it if you can still observe a considerable time lag.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(kohei.yoshino)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.