Closed Bug 1554029 Opened 1 year ago Closed 1 year ago

Updating from 67.0 to staging 67.0.5 release shows "You've launched an older version of Firefox" dialog


(Toolkit :: Startup and Profile System, defect, P1)




Tracking Status
firefox-esr60 --- unaffected
firefox67 blocking verified
firefox67.0.1 blocking verified
firefox68 + verified
firefox69 + verified


(Reporter: nthomas, Assigned: mossop)




(Keywords: regression)


(2 files, 1 obsolete file)

Attached image Dialog

Bug 1547830 comment #27 describes a test scenario for the whatsnew page for Trailhead. I kept getting the profile downgrade dialog (see attachment), which blocks launching Firefox with the existing profile. I could get past that by exporting MOZ_ALLOW_DOWNGRADE=1 prior to launching Firefox.

I was starting with 67.0 and a fresh profile, which had compatibility.ini contents


After a successful update compatibility.ini contained


[Tracking Requested - why for this release]:

I'm concerned we will hit this bug not just on Trailhead but on any point release for 67.0. Since the application version doesn't change during the nightly or beta cycles we have not had an opportunity to test this code in the release case.

Flags: needinfo?(dtownsend)

Can reproduce the problem on win64 too. Also seen on win64 with a single profile, which existed prior to updating to 67.0.

The code used for the test release was m-r@df853c362664989e025d1206b59c37c435186a91 plus a release automation change and setup for a staging release.

Keywords: regression

I wonder if this isn't a stupid versioning math
67.0_20190516215225/20190516215225 > 67.0.5_20190523030228/20190523030228
so, we might have this bug if we create 67.0.1

Yes, it is stupid versioning math...

Assignee: nobody → dtownsend
Flags: needinfo?(dtownsend)
Priority: -- → P1

We build compatibility versions as <appversion>_<appbuildid>/<platformbuildid>.
where the build ID's by default are a numeric representation of the date that
the build happened.

Previously we attempted to mangle this into a valid toolkit version by
converting to <appversion>.<appbuildid>.<platformbuildid> if the build IDs
were the expected length. We also split each build ID into two version parts
since the version comparator couldn't handle their full size.

This mangling fails when comparing a major version with a new patch version:

<majorversion>.<appbuildid>.<platformbuildid> gets compared to
<majorversion>.1.<appbuildid>.<platformbuildid>. Unless that patch version
(1 here) was greater than the build ID (currently in the tens of millions) the
patch release would appear to be older than the previous version.

This changes this so rather than attempting to mangle the entire string into a
single toolkit version we split out the string into their components.

First we compare the app versions using the version comparator which is
definitely the correct thing to do.

For the build IDs we check if they are entirely numeric (which is the case for
the date based default) and if so just compare them numerically.

We assume that if the IDs aren't numeric then they are something defined by a
custom build of Firefox, we can't know what form that takes so I've chosen to
fallback to just using the version comparator since it will handle things such
as "build1" < "build10" and it should be straightforward for anything more
complex to choose a form that works.

QA Whiteboard: [qa-regression-triage]

Comment on attachment 9067496 [details]
Bug 1554029: Downgrade detection fails for changes from non-minor to minor versions. r=froydnj

Beta/Release Uplift Approval Request

  • User impact if declined: Upgrading from Firefox 67.0 to 67.0.1 will tell the user that they are trying to use an older version of Firefox with their profile and force them to create a new profile.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: I have verified this locally but verifying that the update from 67.0 to 67.0.1 would be useful, as would updating from 66 straight to 67.0.1.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The new code is now covered by automated tests so is better tested than previously. The changes are reasonably straightforward. I do think that as code that potentially forces users to create a new profile it deserves scrutiny.
  • String changes made/needed: None
Attachment #9067496 - Flags: approval-mozilla-release?
Attachment #9067496 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by
Downgrade detection fails for changes from non-minor to minor versions. r=froydnj
Flags: needinfo?(dtownsend)
Pushed by
Downgrade detection fails for changes from non-minor to minor versions. r=froydnj

I folded the two patches plus a fix from bug 1555179 into the above.

Flags: needinfo?(dtownsend)
Attachment #9068180 - Attachment is obsolete: true
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Comment on attachment 9067496 [details]
Bug 1554029: Downgrade detection fails for changes from non-minor to minor versions. r=froydnj

Fx67 dot-release blocker. Approved for 68.0b6 and 67.0.1.

Attachment #9067496 - Flags: approval-mozilla-release?
Attachment #9067496 - Flags: approval-mozilla-release+
Attachment #9067496 - Flags: approval-mozilla-beta?
Attachment #9067496 - Flags: approval-mozilla-beta+
Flags: in-testsuite+
Depends on: 1555179
QA Whiteboard: [qa-regression-triage]

I have managed to reproduce the issue using Fx67.0.1 buildID: 20190523132325 using the pave over update method.

The issue is verified fixed using Fx 67.0.1 buildID: 20190529130856 on Ubuntu 18.04 x64, macOS 10.13.6 and Windows 10 x64. The user no longer receives the downgrade protection prompt after the update to the latest version. Updates were performed as instructed, from Fx67.0 and Fx66.0.5 using the regular update and pave over method.

Regressions: 1556832

Just saw the same bug 'in the wild' (7/22/2019) going from 68.0 to 68.0.1. Is this really resolved?

(In reply to charles.roth from comment #16)

Just saw the same bug 'in the wild' (7/22/2019) going from 68.0 to 68.0.1. Is this really resolved?

Yes this bug is resolved. You should open new bugs for new issues.

This continues to happen to me. I have lost hours of time dealing with this. I have gone through all the steps to correct. Reinstalled Firefox many times and the issue persists. It seems that it occurs after Firefox crashes and then I reopen it. Happens every day.

Per the comments above, I've opened new bug for this problem on version 68. So I'm assuming any new comments should go there (please include version numbers and OS). Although it really looks like the same problem.

Duplicate of this bug: 1600110

Please specify a root cause for this bug. See :tmaity for more information.

Root Cause: --- → ?
Root Cause: ? → Coding: Logical Error
You need to log in before you can comment on or make changes to this bug.