${Changeset} unknown in openSUSE Firefox (but ${PlatformChangeset} is known if NTT supports it)

[tonymec]

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0" (en-US) ID:2015091800 CSet:78c82e5cd777

Tested with both the "stable" version 3.7.1-signed from AMO, and the "development" version 3.7pre20131013. Both give "Undefined" for ${Changeset}. The "development" version gives a reasonable value for ${PlatformChangeset}, as shown above with a "customized" nightly.templates.buildid == 'UA:"${UserAgent}" (${Locale}) ID:${AppBuildID}${Flags} CSet:${PlatformChangeset}'

N.B. This Firefox build comes from the latest openSUSE 13.2 x86_64 Firefox package. Please test also with some build from ftp.m.o. and/or releases.m.o. If ${Changeset} is defined on Mozilla Firefox 41.0 for Linux x86_64 then Wolfgang Rosenauer (WolfiR on moznet; mozilla@rosenauer.org), the liaison officer between Mozilla and SUSE, might be interested.

[tonymec]

Let's try in more detail than in the above comment. My default Firefox, living at /usr/local/firefox/firefox with /usr/local/bin/firefox pointing to it, is now the latest trunk nightly from Mozilla. I still have the current openSUSE build (now at openSUSE release Leap 42.1) but after it in the $PATH: /usr/bin/firefox points to /usr/lib64/firefox/firefox.sh

This:

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0" (en-US) ID:20160106030225 CSet:9d6ffc7a08b6b47056eefe1e652710a3849adbf7

is what I get in my default (Mozilla Nightly) Firefox with nightly.templates.buildid set to UA:"${UserAgent}" (${Locale}) ID:${AppBuildID}${Flags} CSet:${Changeset} which IIUC isn't the default anymore. The NTT version installed there calls itself "Nightly Tester Tools 3.7.1-signed" which IIUC means the stable version from AMO.

Replacing ${Changeset} by ${PlatformChangeset} gives

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0" (en-US) ID:20160106030225 CSet:${PlatformChangeset}

because this NTT version is not Platform-Changeset-aware.

Now let's close this Firefox "from Mozilla" and start Firefox "from openSUSE" with the same profile. The titlebar says (thanks NTT) that this is Firefox 43.0.3.

Clicking the NTT button, then "Copy to Cipboard" gives

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0" (en-US) ID:2015122500 CSet:Undefined

Now let's test in even more detail.

Let us clone, package and install the "branch-issue-129-platform-changeset" branch from https://github.com/xabolcs/nightlytt (This may take some time…)
   The resulting XPI calls itself "nightlytt-3.8pre-201601070332.xpi" and is to be found in the "xpi" subdirectory of my clone of xabolcs/nightlytt.
   "This site wants to install an unverified add-on into Firefox, proceed with caution" → [Install]
   "Nightly Tester Tools will be updated after you restart Firefox" → Restart Now
   "/!\ Nightly Tester Tools could not be verified for use with Firefox. Proceed with caution." ("More information" leads to a SUMO page about add-on signing.) → OK, this XPI was indeed (intentionally) not sent to Mozilla for preliminary inspection and (if successful) signing.

With the same nightly.templates.buildid value as above I get the same results (with Undefined) in the openSUSE version.
   Now let's add back the "Platform" between ${ and Changeset}.
   This is what I now get in the openSUSE Firefox 43.0.3:

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0" (en-US) ID:2015122500 CSet:f227eec41a24

and in the Mozilla Firefox 46.0a1:

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0" (en-US) ID:20160106030225 CSet:9d6ffc7a08b6b47056eefe1e652710a3849adbf7

Conclusion:
   In a PlatformChangeset-aware NTT, such as the "development" version at AMO or the somewhat more advanced "branch-issue-129-platform-changeset" branch of xabolcs/nightlytt, both ${Changeset} and ${PlatformChangeset} give the same 40-nybble result in Mozilla builds of Firefox.
   In openSUSE builds, ${Changeset} results in the value "Undefined" while ${PlatformChangeset} gives an abbreviated (12-nybble) hex identifier.

In any version not-PlatformChangeset-aware, ${Changeset} gives the same values as above (including "Undefined" in openSUSE builds), but ${PlatformChangeset} returns the value '${PlatformChangeset}' (without the quotes), as expected.

In Firefox builds from my Linux distro, the Mercurial repository changeset can thus not be obtained from "stable" versions of NTT.

[whimboo]

As far as I know both OpenSuse and ubuntu strip of the changeset from the file application.ini. Can you have a look if opensuse leaves the platform.ini file in the directory?

[tonymec]

There is a platform.ini (at /usr/lib64/firefox/platform.ini) but I don't see any CSID in it. Here is its full text:

; This file is not used. If you modify it and want the application to use
; your modifications, move it under the browser/ subdirectory and start with
; the "-app /path/to/browser/application.ini" argument.
[App]
Vendor=Mozilla
Name=Firefox
RemotingName=firefox
Version=43.0.3
BuildID=2015122500
SourceRepository=http://hg.mozilla.org/releases/mozilla-release
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
[Gecko]
MinVersion=43.0.3
MaxVersion=43.0.3
[XRE]
EnableProfileMigrator=1
[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=43.0.3&buildid=2015122500

The only *.ini in /usr/lib64/firefox/browser is crashreporter-override.ini

[whimboo]

I might have to check the code but it looks like that we do not correctly check if a specific key is not present, or have a sane fallback value.

[xabolcs]

Hello there!

I was able to reproduce this with Suse 11 & with the distributed Firefox ESR 17.0.4.

As @tonymec wrote there is no information about Application's SourceStamp but only Platform's.

The only question here is what to do in this case ... when AppSourceStamp is undefined and PlatformSourceStamp is defined.
Should App fallback to Platform? It's OK to me.

[whimboo]

I think for Firefox it should not be a problem. But for Thunderbird and SeaMonkey we might not want to do it because those revisions are different, e.g. comm-central vs. mozilla-central.

[xabolcs]

OK. I could adjust the logic accordingly in the pull request.

Thanks for the input!