286825 - Firefox.exe is compiled with incorrect Product Version information

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[MorPob]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0 StumbleUpon/1.9991
Build Identifier: All Including Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0 

Knowing what exactly which version of Fx is installed on thier PCs is very
important to corporate customers (for security purposes in particular).

Most software inventory scanners read the the properties of .exe files to
indentify the Product, Vendor and Version infomation.  This is what our sw
inventory scanner gets from the firefox.exe (v1.01.):

Product Name: Firefox
Product Version: 1.7.6: 2005022518
Vendor: Mozilla

This is a little confusing when you are trying to determine the "real" version
of Fx that is installed on PCs on your network.

I know that Product Version of 1.7.6 relates to the version of the gecko engine
however, firefox.exe is not the gecko engine and it should report the Product
Version of firefox not of gecko. Perhaps the gecko engine version (bundled
inside firefox.exe) could be reported in a different (custom?) attribute in the .exe

I think fixing this bug would be very easy to acomplish and I hope we can get it
right for the final compile of Fx 1.0.2 to make corporate adoptors of Fx more
confortable with rolling out Fx.

See http://forums.mozillazine.org/viewtopic.php?t=228219 for more discussion on
this issue.

Reproducible: Always

Steps to Reproduce:
1. right click the firefox.exe (in Windows)
2. select properties
3. click the Version tab
4. select the Product Version attribute.
OR
Run a sofware inventory scaner against a PC with firefox.exe on it and look at
the results
Actual Results:  
Version reported is NOT the Fx version but the Gecko engine version

Expected Results:  
Compile firefox.exe with the version of Fx that it is i.e. 1.0.2 NOT the version
of the Gecko engine

Comment 1

[Ryan VanderMeulen [:RyanVM]]

The official nightlies have the correct build number.  Therefore, I'm willing to
bet it's related to bug 277876.  Try the solution in that bug and see if it
works for you.

Comment 2

[MorPob]

Same problem.  Product Version value is 1.8b2: 2005031806 on the nightly.

Same issue with the Fx 1.0.2 RC @
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-03-17-18-aviary1.0.1/firefox-1.0.2.en-US.win32.installer.exe

Comment 3

[Ali Ebrahim]

This has nothing to do with bug 277876.

As for this bug, I'm indifferent, either way to me sounds fine. For what its
worth, the File Version shows the Firefox version number. But keeping the Gecko
version number somewhere in the file attributes sounds like a good idea too.

Comment 4

[MorPob]

Yes, file version is correct but that really doesn't matter since the most
popular commercial software inventory programs use the Product Version not the
File Version.
I agree that the exe should contain the Gecko version somewhere but not in the
Product Version field.

Comment 5

[Noah (NoahSUMO/SolidSnake) [:Noah]]

Note Morpub: Tiny flub but you seem to spell infoRmation - INFOmation.
You can't fix that in bug description but you can edit the title. Thanks!

Also, I've took a random software's exe properties into account here and found
the following (This may help the decision where to plant Gecko version number as
well as "other" versions):
•Comments
•Special Build Description
•Product Version
•Private Build Description

Now surely one of these can be singled out for a particular entry. Huh?
Or, why the hell can't we add our own entry name (or, "namespace") such as Gecko
 (engine) Version? Unless there's some unwritten rule of thumb that started when
MS was created - Like using only those specific comment entries?

Comment 6

[MorPob]

Attachment: Screen shot of Product Version

Comment 7

[Ali Ebrahim]

MorPob, screenshots are unnecessary for stuff that is plainly apparent to even
those who can't see the bug.

Comment 8

[MorPob]

Can someone that uses MicroSoft's SMS or any other software inventory program on
thier network confirm that it also uses .exe Product Version attributes to
report version information?
I think it is very important that version information is reported correctly to
software inventory tools for corporate adoption of Fx.

Comment 9

[Raanan Barzel]

Notwithstanding any feelings about MS, IE product information seems to convey
all the data which FF tries to convey, in a manner which seems to me to be both
full and useful (Properties panel/Version):

File version: 6.00.2900.2180 (xpsp_sp2_rtm.040803-2158)
Product version: 6.00.2900.2180

FF 1.0.3 currently displays in the same panel:

File version: 1.0.3
Product version: 1.7.7: 2005040301

If Firefox displayed

File version: 1.7.7: 2005040301
Product version: 1.0.3

Then the needed information would be in the expected places. 

This does not seem to me to be of extreme coplexity to implement.

Comment 10

[Mike Mason]

Is there any possibily that we can get this into Fx 1.1?

Comment 11

[Mike Connor [:mconnor]]

Chase, what would it take to get the app version (i.e. 1.0.3) instead of the
Gecko version here?  This is important to corporate deployment types.

Comment 12

[Mike Connor [:mconnor]]

This is something we need for corporate stuff, and I know that versiontracker is
broken by this as well.

Comment 13

[Chase Phillips]

cc'ing devs.  This change is going to be made soon.

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

see:
http://lxr.mozilla.org/seamonkey/source/config/version_win.pl#218

http://lxr.mozilla.org/seamonkey/source/config/version_win.pl#400

changing OS to windows, this does not affect other OSes

Comment 15

[Chase Phillips]

Attachment: Override product version with app version number

While I'm here, bumping Firefox trunk version from 1.0 to 1.0+.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm, should maybe both fileversion and productversion be set?

Comment 17

[Mike Mason]

I'm glad to see this bug being aggresively worked on but I am wondering...
What attribute (of the exe) will the gecko engine version (i.e. 1.7.10:
2005071605) info be put after it is removed from Product Version?

Comment 18

[Chase Phillips]

(In reply to comment #17)
> I'm glad to see this bug being aggresively worked on but I am wondering...
> What attribute (of the exe) will the gecko engine version (i.e. 1.7.10:
> 2005071605) info be put after it is removed from Product Version?

File Version

Comment 19

[Chase Phillips]

(In reply to comment #16)
> hmm, should maybe both fileversion and productversion be set?

They are both set in version_win.pl.  The patch changes which gets the override.

Comment 20

[Mike Mason]

I don't want to be difficult here I would just like us to nail this bug once.
From the poking around I've done in .exe attributes I'm a little confused.  It
looks like there is a long and a short File Version attribute in win32 exes.  
Examples
notepad
short 5.1.2600.2180
long  5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
iexplore.exe
short 6.00.2900.2180
long  6.00.2900.2180 (xpsp_sp2_rtm.040803-2158)
write.exe
short 5.1.2600.0
long  5.1.2600.0 (xpclient.010817-1148)

From those examples it looks like the short version is actually the File Version
 up to the first space.  However I looked at some other(non-MS) exes and they
seem to not conform to that rule (because of a different format in the File
Version?)
Examples
winword.exe
short 11.0.6502.0
long  11.0.6502
winvnc.exe
short 1.2.9.0
long  1, 2, 9, 0

This leads me to believe that either:  1)There two seperate version attributes
(short and long) or 2)The rule(s) for generating the short version are more
complicated that what I originally thought.

Would it be wise to put a custom attribute to the exe like Gecko Build?

Thanks for all your hard work guys, I wish I could help more to solve the issues
and not just give you all more work to do.

Comment 21

[Mike Mason]

I'm thinking now that there is a Short and a Long Verison attribute
acrobat.exe
short 6.0.0.878
long  6.0.0.2003051900

Comment 22

[Chase Phillips]

Comment on attachment 190279 [details] [diff] [review]
Override product version with app version number

Landed on the trunk.

Checking in config/version_win.pl;
/cvsroot/mozilla/config/version_win.pl,v  <--  version_win.pl
new revision: 3.11; previous revision: 3.10
done
Checking in browser/app/module.ver;
/cvsroot/mozilla/browser/app/module.ver,v  <--	module.ver
new revision: 1.11; previous revision: 1.10
done
Checking in mail/app/module.ver;
/cvsroot/mozilla/mail/app/module.ver,v	<--  module.ver
new revision: 1.7; previous revision: 1.6
done

Comment 23

[Mike Mason]

I'm glad to see that this bug got resolved, thank you.  Software inventory
scanners now report Firefox version 1.0+.

However, I wonder in general about the entire versioning scheme for Fx.  1.0+
does not really disclose very much information about the firefox.exe build. 
With this versioning system there would be no distinguishment between any
nightlies and build canidates.
Would the entire versioning scheme not be more usefull if it were something like
1.06.20050728xx to reflect the build number?

I can't think of a reason why not to use this scheme.  It would also make it
easier for the 1.5 builds (extensions and themes in particular) with all DP
nightlies, candidates and release being 1.50.yyyymmddbb.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

(In reply to comment #23)
> I'm glad to see that this bug got resolved, thank you.  Software inventory
> scanners now report Firefox version 1.0+.
> However, I wonder in general about the entire versioning scheme for Fx.  1.0+
> does not really disclose very much information about the firefox.exe build. 
> With this versioning system there would be no distinguishment between any
> nightlies and build canidates.
> Would the entire versioning scheme not be more usefull if it were something 
like
> 1.06.20050728xx to reflect the build number?
> I can't think of a reason why not to use this scheme.  It would also make it
> easier for the 1.5 builds (extensions and themes in particular) with all DP
> nightlies, candidates and release being 1.50.yyyymmddbb.

I don't mean to offend you, but this isn't Mozillazine. The reply is off-topic 
for this bug. If you don't like it, file a new one (though I'm pretty sure 
they're taking steps to avoid using "+" stuff in the future) or post in on 
Mozillazine. But don't spam bugs with off-topic content please, for the sake 
of those of us who are on the CC list and don't want to wade through spam.