726781 - No way to distinguish between Firefox release and Firefox ESR via the registry

Status: RESOLVED FIXED

(Firefox :: Installer, defect)

Description

[ghoffer]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.46 Safari/535.11

Steps to reproduce:

Using SCCM to detect, deploy and update Firefox and Firefox ESR.


Actual results:

Registry info is exactly the same for both Firefox and Firefox ESR.  This makes it impossible to provide software updates, run inventories or reports via such systems as SCCM as the system will see no difference between the two versions.  Additionally, whereas file versions between Firefox 10 and Firefox 10.0.1 did differ (10.0.0.4411 and 10.0.0.4412, respectively), the file versions between Firefox 10.0.1 and Firefox 10.0.1 ESR are exactly the same (10.0.1.4421).

This behavior will cause a lot of frustration for enterprises which often use such system management servers as SCCM.


Expected results:

The registry info added when Firefox ESR is installed should clearly indicate it is an ESR version.

Comment 1

[Robert Strong (they/them - no direct email)]

Has to be done at the app level so moving to Firefox -> Installer.

Note: the different builds can already be done by reading the defaults/prefs/channel-prefs.js file or the application file which is much more authoritative than the registry especially since we don't require Firefox to be added to the registry in order to run.

Comment 2

[ghoffer]

SCCM detects software using registry info, file info or a WMI query.  It reads file metadata and attributes such as the file version.

There's no way for SCCM (and many other popular system management services that are leveraged heavily in the enterprise sector) to read the defaults/prefs/channel-prefs.js file.

Comment 3

[Robert Strong (they/them - no direct email)]

Understood which is why this bug isn't wontfix'd. I was just pointing out that the registry won't be authoritative since it isn't 100% tied to the program itself.

Comment 6

[u498376]

Why can't it be a registry addition that the installer adds for ESR installs.

If you add the term ESR someplace under the Mozilla Firefox registry key this would be extremely useful going forward.

Currently the following Key's Value data is in the format of <version> <language/local> example would be "27.0 (en-US)"

HKLM\SOFTWARE\Mozilla\Mozilla Firefox\CurrentVersion

If you changed this value's data to be "27.0esr (en-US)" then that would be great however for some people this could be a breaking change.

To be safer you could add a new DWORD value like "IsESR" with a 0 being false and 1 being true. This could be set to one only when an ESR is installed and not even exist if on standard releases. Or for consistency having it always exist going forward wouldn't hurt anything.

It seems like a simple thing to have an IsESR in the registry placed by the installer. If the application changes subscription channels for updates then the registry entry can be flipped from true to false or false to true by the application itself.  

Right now reading a text file is not useful. 

I am not sure why this is not addressed after two years. ESR was supposed to be for Enterprises what need extended support of a specific version, however you are limiting the ability of Enterprises that use a very popular product provided my Microsoft to detect, and update your ESR product. Which makes the ability for Enterprises to meet their compliance requirements more difficult.

Also this is for all platforms, not just Windows 7, that should be updated. I couldn't change it.

Comment 7

[Robert Strong (they/them - no direct email)]

Two years because there are plenty of other bugs that are just as important and affect a much greater number of people.

Other platforms don't have a registry and there would need to be a much different solution that doesn't involve an installer since the other platforms don't have an installer (I agree that people often think of the dmg as an installer but it isn't). Please file bugs for the other platforms in Firefox -> General if you would like that capability.

Comment 8

[u498376]

Mac and Linux don't have registries however you are providing version, and language and installation path in the Windows Registry. What we Windows Administrators are asking you is nothing different but to add a way to detect ESR via the Registry as well, just like we can currently detect your VERSION and LANGUAGE via the registry.

Who said anything about Mac? This is a Feature Request/Bug WINDOWS. Linux and Mac in Enterprises have ways where using a text file to determine ESR or not is not an issue.  

This issue is explicitly to solve a problem for MICROSOFT Windows Administrators who use System Center Configuration Manager and System Center Updates Publisher. Therefore as a first pass release you ONLY have to add the IsESR (or something like) to your common registry key during the installation. If they change from one to the other the INSTALLER of that new version can change the registry key. This can be isolated to only the Windows Installer and the Windows Registry.

I think you guys have been over complicating this issue and trying to resolve it for all platforms, but this is not an issue on all platforms, this is only an issue on the Windows platform.

Comment 9

[Robert Strong (they/them - no direct email)]

(In reply to Rodney Foley from comment #6)
>...
> Also this is for all platforms, not just Windows 7, that should be updated.
> I couldn't change it.
Oh, you meant different versions on the Windows platform and not all platforms.

No, we aren't trying to solve it for all platforms.

Comment 10

[Robert Strong (they/them - no direct email)]

BTW: if I can find the time over the weekend I will try to come up with a fix for this bug. I understand why people would want it but it isn't as simple as you make it out to be.

Comment 11

[u498376]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #10)
> BTW: if I can find the time over the weekend I will try to come up with a
> fix for this bug. 

That is great, your time on this is greatly appreciated!

Comment 12

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Sorry for not getting back to this sooner.

Brian, this is a little fragile since it relies on a string in the application.ini to determine if this is an esr release but I think it is safe enough to use.

Comment 13

[u498376]

Hi Robert,

I appreciate the work on the install script all those locations look like great places in the registry to add it. The we will look forward to the most is where "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox" becomes "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox ESR" as that will be perfect for use with the SCUP tool from Microsoft.

I look forward to the first release that will take advantage of this going forward.

I know I am not Brian, but I agree that it could be fragile but is safe enough. It just requires any changes to the application.ini to continue to provide mozilla-esr for any of your ESR releases for any of your products.

Thanks again Robert.

Comment 14

[Brian R. Bondy [:bbondy]]

Comment on attachment 8394513 [details] [diff] [review]
patch rev1

Review of attachment 8394513 [details] [diff] [review]:
-----------------------------------------------------------------

Instead of reading the application.ini couldn't we just pass a define to nsis here:
http://dxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/defines.nsi.in#80

In this case:
if CONFIG['MOZ_UPDATE_CHANNEL'] in ('esr'):

Would be cleaner/smaller/more maintainable if so, but I'm assuming you have a reason why we can't do that.

Comment 15

[Robert Strong (they/them - no direct email)]

When the first Firefox XX is built where Firefox XX is also Firefox XX ESR I am fairly certain that they use the same bits. It might be possible to recompile the installer during the repackaging when the channel-prefs.js file is modified but I suspect it would be somewhat complicated.

Comment 16

[Brian R. Bondy [:bbondy]]

Comment on attachment 8394513 [details] [diff] [review]
patch rev1

Review of attachment 8394513 [details] [diff] [review]:
-----------------------------------------------------------------

Fair enough.

Comment 17

[Robert Strong (they/them - no direct email)]

Comment on attachment 8394513 [details] [diff] [review]
patch rev1

Nick, just want to check with you as to whether there is a better way to get whether the build is an esr build during build time per my statement in comment #15. Thanks!

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

We use almost the same source for the two builds (eg 24.0 and 24.0esr), mainly browser/confvars.sh changes for the mar channel id. The source comes from different repositories and we do separate compilations,  which allows for build time changes based on the channel. This sounds like another one of those cases, so Brian's suggestion would be an option.

Comment 19

[Robert Strong (they/them - no direct email)]

Attachment: patch rev2

Changed the patch to use ${UpdateChannel}

Comment 20

[Robert Strong (they/them - no direct email)]

interdiff should suffice

Comment 21

[Robert Strong (they/them - no direct email)]

Comment on attachment 8395858 [details] [diff] [review]
patch rev2

Forgot to fix the channel name

Comment 22

[Robert Strong (they/them - no direct email)]

Attachment: patch rev3

Comment 23

[Martin Sapsed]

(In reply to Rodney Foley from comment #13)
> Hi Robert,
> 
> I appreciate the work on the install script all those locations look like
> great places in the registry to add it. The we will look forward to the most
> is where "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox"
> becomes "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox
> ESR" as that will be perfect for use with the SCUP tool from Microsoft.

I disagree that that is where the change should only appear. The primary area in the Windows registry for information about what software is installed and what version is the with the data that drives Add/Remove programs - under 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
(with Wow6432Node in the path on x64)
Firefox creates a version specific key under there called e.g. "Mozilla Firefox 24.3.0 (x86 en-GB)" and in that key are several values including "DisplayVersion" which in this case contains 24.3.0.
I would argue this key should have the value "24.3.0 ESR" for the ESR version.
The data under the Uninstall tree is where Symantec's Altiris system looks for installed software inventory and I'm sure it's not the only one. Changing a Mozilla Firefox specific key is too, well, specific really!

Comment 24

[u498376]

Who said anything about these changes "should only appear" anywhere? In that quote I said "those locations look like great places" I never said anything about this being the ONLY place. I am not a fan of being misquoted or misrepresented so I will try to make it very clear below.

I am an Enterprise user who requested a feature in order to be able to detect a Mozilla ESR and non-ESR product via registry values that can be used by Microsoft's System Center Updates Publisher 2011 for use within System Center Configuration Manager 2007 and 2012.  The two key values are the default value and the CurrentVersion value under sub-key (in the case of Firefox) Mozilla\Mozilla Firefox with the default value needing to remain just the full version and the CurrentVersion having ESR added to it.

Please feel free splash "ESR" or anything else you may need anyplace you want in the registry as I have never said anything suggesting you should not do that. I and other Enterprise SCCM admins only request that the changes planned for ESR to the CurrentVersion under the Mozilla/Mozilla Firefox subkey would remain.

Again I really appreciate all the work you guys are doing to get the changes in for this, so please don't take my response to being misquoted poorly.

Comment 25

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/ff57a7b6f167

Comment 26

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/ff57a7b6f167

Comment 27

[Martin Sapsed]

Rodney - please accept my apologies - I appear to have worded my message badly. I've been arguing for a change like this on the Enterprise mailing list too on and off. I only saw your reg paths explicitly suggested here and was concerned that the coders would think the job was done after doing those, and miss the uninstall tree. 

Looking at the code submissions above it appears that both are planned so we should both be happy!