Updating from 67.0 to staging 67.0.5 release shows "You've launched an older version of Firefox" dialog
Categories
(Toolkit :: Startup and Profile System, defect, P1)
Tracking
()
People
(Reporter: nthomas, Assigned: mossop)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files, 1 obsolete file)
53.27 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-release+
|
Details | Review |
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
[Compatibility]
LastVersion=67.0_20190516215225/20190516215225
LastOSABI=Darwin_x86_64-gcc3
LastPlatformDir=/Applications/Firefox.app/Contents/Resources
LastAppDir=/Applications/Firefox.app/Contents/Resources/browser
After a successful update compatibility.ini
contained
[Compatibility]
LastVersion=67.0.5_20190523030228/20190523030228
LastOSABI=Darwin_x86_64-gcc3
LastPlatformDir=/Applications/Firefox.app/Contents/Resources
LastAppDir=/Applications/Firefox.app/Contents/Resources/browser
[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.
Reporter | ||
Comment 1•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 2•5 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
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.
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Pushed by dtownsend@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a47c0e5f3520 Downgrade detection fails for changes from non-minor to minor versions. r=froydnj
Assignee | ||
Comment 7•5 years ago
|
||
This is just addressing the final review comments at https://phabricator.services.mozilla.com/D32552.
Comment 8•5 years ago
|
||
Backed out for causing GTest perma failures.
Backout: https://hg.mozilla.org/integration/autoland/rev/6f75ea6173eb7f3e0e1a75e3da7e2d05471081d9
Updated•5 years ago
|
Pushed by dtownsend@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/258c332f0058 Downgrade detection fails for changes from non-minor to minor versions. r=froydnj
Assignee | ||
Comment 10•5 years ago
|
||
I folded the two patches plus a fix from bug 1555179 into the above.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
bugherder |
Comment 12•5 years ago
|
||
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.
Comment 13•5 years ago
|
||
uplift |
Updated•5 years ago
|
Comment 14•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Comment 15•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 16•5 years ago
|
||
Just saw the same bug 'in the wild' (7/22/2019) going from 68.0 to 68.0.1. Is this really resolved?
Assignee | ||
Comment 17•5 years ago
|
||
(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.
Comment 18•5 years ago
|
||
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.
Comment 19•5 years ago
|
||
Per the comments above, I've opened new bug https://bugzilla.mozilla.org/show_bug.cgi?id=1568252 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.
Comment 21•4 years ago
|
||
Please specify a root cause for this bug. See :tmaity for more information.
Assignee | ||
Updated•4 years ago
|
Updated•2 years ago
|
Description
•