The default bug view has changed. See this FAQ.

Make the full Build ID more accessible to testers

VERIFIED FIXED

Status

()

Core
General
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: zach, Assigned: zach)

Tracking

({privacy, verified1.8.1})

Trunk
privacy, verified1.8.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Assignee)

Description

11 years ago
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.

Comment 2

11 years ago
Related bug, and possible dup of your first proposal: bug 150351
(Assignee)

Comment 3

11 years ago
Created attachment 230984 [details] [diff] [review]
Add navigator.buildID and replace short build id in about dialog with full build id

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.
(Assignee)

Comment 4

11 years ago
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+
(Assignee)

Comment 6

11 years ago
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.
Attachment #230984 - Flags: review?(mconnor)
(Assignee)

Comment 7

11 years ago
Created attachment 231174 [details] [diff] [review]
patch v2: change about: but leave the about dialog alone

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 #230984 - Attachment is obsolete: true
Attachment #231174 - Flags: review?
Attachment #230984 - Flags: review?(mconnor)
(Assignee)

Updated

11 years ago
Attachment #231174 - Flags: review? → review?(mconnor)
(Assignee)

Comment 8

11 years ago
Created attachment 231459 [details] [diff] [review]
v3: incorporate rob_strong's comments
Attachment #231174 - Attachment is obsolete: true
Attachment #231459 - Flags: review?
Attachment #231174 - Flags: review?(mconnor)
(Assignee)

Updated

11 years ago
Attachment #231459 - Flags: review? → review?(robert.bugzilla)
Attachment #231459 - Flags: review?(robert.bugzilla) → review+
Whiteboard: [checkin needed]
(Assignee)

Comment 9

11 years ago
Landed on trunk thanks to rob_strong. 
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]

Comment 10

11 years ago
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

Comment 11

11 years ago
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.
(Assignee)

Comment 12

11 years ago
Created attachment 231615 [details] [diff] [review]
Branch version - no changes made

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.)
(Assignee)

Comment 15

11 years ago
Created attachment 231970 [details] [diff] [review]
Branch patch v2

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 #231615 - Attachment is obsolete: true
Attachment #231970 - Flags: superreview?
(Assignee)

Updated

11 years ago
Attachment #231970 - Flags: superreview? → superreview?(jst)
Comment on attachment 231970 [details] [diff] [review]
Branch patch v2

sr=jst
Attachment #231970 - Flags: superreview?(jst) → superreview+
(Assignee)

Comment 17

11 years ago
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 18

11 years ago
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.

Comment 20

11 years ago
I see that for non official builds, the about: page raises a Javascript error:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNavigator.buildID]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: about: :: <TOP_LEVEL> :: line 80"  data: no]

And the line "Build identifier:" becomes empty. 

I guess that's because the build id of non official builds is 0000000000, so the if is not taken.

Is this the intended behavior?
Adding missing keyword - branch patch landed at 2006-08-04 11:23 PDT.

Bug 348069 deals with comment #20.
Keywords: fixed1.8.1
Depends on: 348069

Updated

11 years ago
Blocks: 335382

Updated

11 years ago
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
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.
Keywords: privacy
(In reply to comment #20)
> Is this the intended behavior?

I don't think so, I've filed bug 351601 on this issue.

Updated

11 years ago
Blocks: 351601
You need to log in before you can comment on or make changes to this bug.