Firefox 67 in Ubuntu 18.10 thinks it's an older version

Created attachment 9066781
compatibility.ini

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

On 2019-05-21 I updated my computer from Ubuntu 18.04 to 19.04. I'm not sure if Firefox was updated to Firefox 67 prior to my upgrade. I was not using any nightly or developer versions.

Actual results:

When loading Firefox an error window came up with the following text:
> Using an older version of Firefox can corrupt bookmarks and browsing history already saved to an existing Firefox profile. To protect your information, create a new profile for this installation of Firefox.

Expected results:

Firefox should have loaded my profile without issue.

Just a comment that I was directed here from Reddit and told to upload the compatibility.ini file from the old profile.

Just to check, are you using the Ubuntu provided version of Firefox or are you using one downloaded directly from Mozilla?

This was reported as an ubuntu bug: https://bugs.launchpad.net/firefox/+bug/1830096.

It seems unfortunate that firefox uses MOZ_BUILD_DATE as its build ID (if I followed correctly the code path, see https://hg.mozilla.org/mozilla-central/file/tip/build/variables.py#l15).

The official build from Mozilla might not be affected by that bug, but on Ubuntu we build firefox for each supported release (at present that's 16.04, 18.04, 18.10, 19.04 and the development series, 19.10), which means that the same package of firefox for two different Ubuntu releases will be getting different build IDs, and there's no way to guarantee that the build ID for release X will be < the build ID for release Y, where X < Y (other than building the packages sequentially, instead of in parallel).

I wonder whether setting MOZ_BUILDID to the Ubuntu package version string (e.g. "67.0+build2-0ubuntu0.19.04.1") when building would fix the problem, and wouldn't introduce undesirable side effects?

(In reply to Dave Townsend [:mossop] (he/him) from comment #2)
> Just to check, are you using the Ubuntu provided version of Firefox or are you using one downloaded directly from Mozilla?

I'm using the Ubuntu provided version, both before and after upgrading.

(In reply to Olivier Tilloy from comment #3)
> It seems unfortunate that firefox uses MOZ_BUILD_DATE as its build ID (if I followed correctly the code path, see https://hg.mozilla.org/mozilla-central/file/tip/build/variables.py#l15).

My apologies, I hadn't noticed that this was the case.

> The official build from Mozilla might not be affected by that bug, but on Ubuntu we build firefox for each supported release (at present that's 16.04, 18.04, 18.10, 19.04 and the development series, 19.10), which means that the same package of firefox for two different Ubuntu releases will be getting different build IDs, and there's no way to guarantee that the build ID for release X will be < the build ID for release Y, where X < Y (other than building the packages sequentially, instead of in parallel).

If the builds for each release are from the same source then I don't think it would be an issue for the Firefox build ID to match across those builds, though I also imagine that sharing profiles between different Ubuntu releases is going to be rare.

The chief thing that we care about is that if the Firefox code is newer then it should have a larger compatibility version than previously. The compatibility version is defined as `<version>_<appbuildid>/<platformbuildid>` (the latter two are the same in Mozilla builds). We compare as if the string is a valid toolkit version (https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format), and to make that the case we do some special parsing in the case where the buildid is the expected number of characters that are generated from Mozilla builds, otherwise we just use the literal compatibility version for comparison.

I am not sure about other uses of the build ID in Firefox, but I think one viable option is just to set the build ID to your "build2". This would lead to a compatibility version like `67.0_build2/build2`. This would fall back to just interpreting that as a full version string which looks like it compares correctly:

```
"67.0_build1/build1" < "67.0_build2/build2"
"67.0_build3/build3" > "67.0_build2/build2"
"67.0_build3/build3" < "67.1_build2/build2"
"67.0.1_build1/build1" < "67.1_build2/build2"
"67.0.1_build1/build1" > "67.0_build2/build2"
```

What do you think of that?

(In reply to Dave Townsend [:mossop] (he/him) from comment #6)

> If the builds for each release are from the same source then I don't think it would be an issue for the Firefox build ID to match across those builds, though I also imagine that sharing profiles between different Ubuntu releases is going to be rare.

Indeed this wouldn't be an issue, rather a logical thing: two binary packages of the same version of firefox (sharing a single source package) have the same build ID.

> The chief thing that we care about is that if the Firefox code is newer then it should have a larger compatibility version than previously. The compatibility version is defined as `<version>_<appbuildid>/<platformbuildid>` (the latter two are the same in Mozilla builds). We compare as if the string is a valid toolkit version (https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format), and to make that the case we do some special parsing in the case where the buildid is the expected number of characters that are generated from Mozilla builds, otherwise we just use the literal compatibility version for comparison.
>
> I am not sure about other uses of the build ID in Firefox, but I think one viable option is just to set the build ID to your "build2". This would lead to a compatibility version like `67.0_build2/build2`.
>
> […]
>
> What do you think of that?

This makes sense to me, and sounds like it would work. Note that "build2" in that context comes from the upstream build candidate, it's not an Ubuntu-specific thing: https://ftp.mozilla.org/pub/firefox/candidates/67.0-candidates/.

I am testing this suggestion, and it appears to work as expected.
Would the following patch be acceptable?

    --- a/build/variables.py
    +++ b/build/variables.py
    @@ -13,10 +13,12 @@ SOURCESTAMP_FILENAME = 'sourcestamp.txt'

     def buildid_header(output):
    - buildid = os.environ.get('MOZ_BUILD_DATE')
    - if buildid and len(buildid) != 14:
    - print('Ignoring invalid MOZ_BUILD_DATE: %s' % buildid, file=sys.stderr)
    - buildid = None
    + buildid = os.environ.get('MOZ_BUILDID')
    + if buildid is None:
    + buildid = os.environ.get('MOZ_BUILD_DATE')
    + if buildid and len(buildid) != 14:
    + print('Ignoring invalid MOZ_BUILD_DATE: %s' % buildid, file=sys.stderr)
    + buildid = None
         if not buildid:
             buildid = datetime.now().strftime('%Y%m%d%H%M%S')
         output.write("#define MOZ_BUILDID %s\n" % buildid)

I.e. prioritize the `MOZ_BUILDID` environment variable over `MOZ_BUILD_DATE`, if it is set.

(In reply to Olivier Tilloy from comment #8)
> I am testing this suggestion, and it appears to work as expected.

Ok, so the patch looks ok to me, though it would really need a build config peer to look at it. But we've discovered another issue related to how we compare the compatibility versions in bug 1554029 so we are going to be making changes to that. I suspect that what we change will still work for the suggestion above but while I realise this is an important issue for you it might be worth holding off any changes on your end until there is an accepted patch there. I'm hoping to have something written today.

Fair enough, I'll hold off changes until bug 1554029 is fixed. Thanks Dave!

Ok so it looks like bug 1554029 has landed and stuck and will be rolling out in a 67.0.1 soon. During testing of that I found that the suggestion I made in comment 6 would have actually only worked on some platforms due to a bug in the version comparator code. It probably would have worked on Linux but now the code is fixed it that changes things a little.

If you care about your users being able to upgrade from a version with the old-style build ID (14 digits based on the date) then either you need to:

1. Continue to use a purely numeric build ID that is larger each time you build (and the first must be larger than the last build ID your users have).

2. Switch to a build ID that can be parsed by the toolkit version code (https://developer.mozilla.org/en-US/docs/Mozilla/Toolkit_version_format) and must contain a character that is not a digit in it (or Firefox will just parse it as a number) and do the above.

For the second option in the first upgrade where users are switching from the old build ID to your new one the version comparator will consider the old build ID to be "0" because the number is too large and overflows. So for your new build ID to be larger than that then it has to be a valid version considered larger than or equal to 0. Mostly that means it must start with at least one digit so "1build1" would work (and then after "1build2" etc. would be considered larger.

It's a little uglier than I'd like unfortunately but it should work.

*** Bug 1557014 has been marked as a duplicate of this bug. ***

Based on this needing an ubuntu change at this point I'm going to close this out.

*** Bug 1555986 has been marked as a duplicate of this bug. ***

I also experienced similar, but in my case I have my usual aarch64 client with /home on a NFS mount using ff67.
What happens is upon occasion mozilla apps (amongst others) from the server direct (using, for example, ssh -Y).

Firefox seems to change the LastOSABI in compatibility to Linux_x64_86-gcc3 from Linux_aarch64-gcc3 whereupon
the next time I launch firefox from my habitual client I get the message (like above)
> Using an older version of Firefox can corrupt bookmarks and browsing history already saved to an existing Firefox profile. To protect your
> information, create a new profile for this installation of Firefox.

Created attachment 9077386
Bug 1553554 - Allow overriding the default build ID with a MOZ_BUILDID environment variable.

Dave, I have submitted https://phabricator.services.mozilla.com/D37722 for review, I hope you and other build config experts can comment.

I have tested this with Ubuntu packages, setting the build ID to e.g. "build3". Your suggestion of prefixing the build ID with a number (i.e. 1build3) doesn't seem necessary if we ensure that this change becomes effective only in a new version of firefox, because the build ID won't matter in the version comparison, e.g. from 68.0_20190701120911/20190701120911 to 68.0.1_build1/build1.

Or am I missing a use case?

(In reply to Olivier Tilloy from comment #17)
> Dave, I have submitted https://phabricator.services.mozilla.com/D37722 for review, I hope you and other build config experts can comment.
>
> I have tested this with Ubuntu packages, setting the build ID to e.g. "build3". Your suggestion of prefixing the build ID with a number (i.e. 1build3) doesn't seem necessary if we ensure that this change becomes effective only in a new version of firefox, because the build ID won't matter in the version comparison, e.g. from 68.0_20190701120911/20190701120911 to 68.0.1_build1/build1.
>
> Or am I missing a use case?

Ah yes, you are right. As long as for a single "version" you use the same build id style you should be fine.

I'm confused at to why a MOZ_BUILDID "override" is necessary for you, and why the build date is a problem in the first place.

Created attachment 9078090
Bug 1553554 - Minor syntactic change (use "not" instead of "is None").

Depends on D37722

THIS IS STUPID!
The problem is arising in Ubuntu because the builds against the current supported versions of Ubuntu have differing BuildIDs. This is because some stupid idiot chose to use the build time as the BuildID. Whoever that was needs teaching some lessons in basic software design and development. what makes it worse is the the BuildID is hard-coded into the specific install.

It is wrong to say that it would be rare for someone to have more than one version of Ubuntu and be sharing profiles across those installations. I know quite a few folk who try differing versions of Ubuntu and do just that. In my case, I have a current build of Xfce 19 amd64 and Cinnamon 18 amd64 on the same machine and also have Xfce 18 i386 on a very useful but old-ish netbook for work during travelling. I share profiles. The build of Firefox is EXACTLY the same version (68.0.1) on all three -- SO WHY THE F**K CAN'T I SHARE PROFILES!!???

There is a clear and obvious solution to this. Firefox HAS and EXISTING and PERFECTLY VALID Build ID.... SourceStamp. For what unearthly reason is that NOT being used as the means of identifying whether the profile is workable for the installed version of Firefox. Given that the rest of the profile coding is platform independent, this should be perfectly sufficient.

Go to work boys!!