Currently the full Build ID in Mozilla products is extremely inaccessible to testers--it is available only in talkback's master.ini file (assuming talkback is installed) and in the application binary itself (available only through nsIXULAppInfo with chrome privs). While the about dialog provides a truncated build id (without the hour), the full build id is very difficult for users to access. QA, Build/Release, and our testing community need the full build id in order to track the testing process and to prepare updates. The inaccessibility of the full build id is also an issue for Litmus. It is very difficult for casual testers to get the full build id, but we need this information in order to track their results. Litmus is able to auto-detect most information about testers' system configurations from the UA, but unless codebase principles are enabled, there is no way to detect the full build id, and the instructions for manually retrieving it from the master.ini file are rather complex for casual testers. As such, I propose the following three enhancements: 1) Display the full build id in the Firefox and Thunderbird about boxes instead of the truncated build id. These about boxes currently display the user agent, but a simple substitution on the build id could be used to add the missing digits. 2) Display the full build id on about:buildconfig. 3) Make the full build id accessible from non-privileged script. I propose navigator.buildID for this purpose. Litmus and other testing tools can use this to automatically populate the build id field for users.
I have a simple windows shortcut to compatibility.ini on my desktop, that mostly even gets updated when Firefox fails to start up, because it is one of the first things that are written to the profile.
Related bug, and possible dup of your first proposal: bug 150351
Here's a patch to do 1) and 3) above. For a variety of reasons related to our build system, I'm avoiding adding it to about:buildconfig, as it's relatively redundant if we have the full build id in the about dialog. Suggestions on good reviewers would be appreciated.
Comment on attachment 230984 [details] [diff] [review] Add navigator.buildID and replace short build id in about dialog with full build id jst -- can you look at the DOM changes here?
Attachment #230984 - Flags: review?(jst)
Comment on attachment 230984 [details] [diff] [review] Add navigator.buildID and replace short build id in about dialog with full build id r=jst for the DOM changes.
Attachment #230984 - Flags: review?(jst) → review+
Comment on attachment 230984 [details] [diff] [review] Add navigator.buildID and replace short build id in about dialog with full build id mconnor: could you please review the about dialog change? You seem to be the mostly likely candidate for this, but if there's someone else you recommend, that would be great too.
Reflecting mconnor's thoughts on IRC today, here's a new patch that displays the full build id in the about: page but leaves the about dialog alone (we'll have to tackle this for thunderbird another way, but that's a different problem). This should keep risk to a minimum, but still allows the full build id to be accessible from script with navigator.buildID and from the UI with the about: page. r=jst carries over for the DOM change. mconnor: Does this cover your concerns about this?
Attachment #231174 - Flags: review? → review?(mconnor)
Attachment #231459 - Flags: review? → review?(robert.bugzilla)
Attachment #231459 - Flags: review?(robert.bugzilla) → review+
Landed on trunk thanks to rob_strong.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060731 Minefield/3.0a1 ID:2006073118 [cairo] landed ? http://img444.imageshack.us/img444/9529/buildidat1.jpg
pal-moz, if you would have read comment 7 you would've noticed that this is only going to be visible in about:, not Help > About Firefox.
Here's a version for the branch -- nothing changed besides some context in the diff that was causing the patch not to apply cleanly. This is a very simple patch with minimal risk that would make life easier for QA, build, and testing contributors for the rest of the 1.8.1 branch lifetime.
Attachment #231615 - Flags: approval1.8.1?
Comment on attachment 231615 [details] [diff] [review] Branch version - no changes made We can't take this on the branch because of the interface changes.
Attachment #231615 - Flags: approval1.8.1? → approval1.8.1-
(Note that this could be done without interface changes, you just need to make a _MOZILLA_1_8_BRANCH interface to avoid changing the existing one.)
Here's a patch for the branch that avoids changing existing interfaces. jst: There really aren't any significant changes from the trunk patch besides the _MOZILLA_1_8_BRANCH interface, but as I don't really know what I'm doing here, I'd appreciate it if you could take a look at this and let me know if I've done anything too stupid.
Attachment #231970 - Flags: superreview? → superreview?(jst)
Comment on attachment 231970 [details] [diff] [review] Branch patch v2 sr=jst
Attachment #231970 - Flags: superreview?(jst) → superreview+
Comment on attachment 231970 [details] [diff] [review] Branch patch v2 Requesting approval for the new and improved branch patch without interface changes.
Attachment #231970 - Flags: approval1.8.1?
Comment on attachment 231970 [details] [diff] [review] Branch patch v2 a=schrep for drivers.
Attachment #231970 - Flags: approval1.8.1? → approval1.8.1+
Comment on attachment 231970 [details] [diff] [review] Branch patch v2 > DOM_CLASSINFO_MAP_ENTRY(nsIDOMNavigator) >+ DOM_CLASSINFO_MAP_ENTRY(nsIDOMNavigator_MOZILLA_1_8_BRANCH) It's correct to list both? I seem to recall somebody saying the opposite recently, although I'm not sure.
Adding missing keyword - branch patch landed at 2006-08-04 11:23 PDT. Bug 348069 deals with comment #20.
I'm not keen on the true buildID being available to any random web page for users who have gone to the trouble of spoofing their UA. Filed bug 350521 on making this behave the same as similar properties like nsNavigator::GetAppName.
(In reply to comment #20) > Is this the intended behavior? I don't think so, I've filed bug 351601 on this issue.
You need to log in before you can comment on or make changes to this bug.