341174 - Help > About Camino Should Display Full UA String

Status: VERIFIED WONTFIX

(Camino Graveyard :: General, enhancement)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2 Mnenhy/0.7.4.0
Build Identifier: Camino Version 2006021400 (1.0)

My daughter uses Camino on her Mac.  I asked her for the user agent (UA) string.  She sent me "Version 2006021400 (1.0)".  In a phone call today, she said that is all she sees when she selects [Help > About Camino] from her menu bar.  

The complete UA string should be displayed to allow users to communicate their configuration accurately.  Further, the UA string should be displayed in a manner that allows the user to mark and copy the string from the About window, to be pasted elsewhere.  

Reproducible: Always




This problem was noted because of the following:  

As a resident of Canada, my daughter had to participate in the recent national census.  She attempted to use the Web to access and complete the census questionnaire, but the Web site would not allow the use of Camino.  Instead, she had to use Safari.  

When my daughter told me about this, I offered to submit a Tech Evangelism bug report via Bugzilla on her behalf.  For that, I asked her for her UA string.  That is when we discovered that Camino does not display a full UA string.  

By the way, now that the Canadian census is over, their Web site has been fixed to allow access by Camino.  No Tech Evangelism bug is needed.  

If anyone needs to contact my daughter about this bug report, please contact me instead.

Comment 1

[froodian (Ian Leue)]

I'm pretty sure that this is impossible, since the "about" window is made at compile time, and the UA string can be changed.  In the future, if your daughter needs the UA string, have her enter javascript:document.write(navigator.userAgent) into the location bar.

Comment 2

[Wevah (Nate Weaver)]

To clarify: the info in the about dialog is *inserted* at runtime, but the files it pulls from are created at compile time and not dynamic (we use the standard Cocoa about window).

Comment 3

[David E. Ross]

This is no less valid than Thunderbird bug #230182, which addresses the same problem in that product.  

I do not understand why, if the complete UA string is available to me via the $HTTP_USER_AGENT variable (Apache Web server) when my daughter visits my own Web site, the string is not available to my daughter via About Camino.

Not being a Mac user myself, I don't know what Cocoa is.  In any case, I would think the About window should standardize to what other Mozilla products use (or, in the case of Thunderbird, should use per the comments on that bug).

Comment 4

[Wevah (Nate Weaver)]

Cocoa is the Mac API that Camino uses for its chrome, and it has a built-in basic "about" window that apps can use (and many do). All of the strings in the window are imported from files inside the application, but those files are static.

We could roll our own about box, but I know there are more pressing bugs.

Changing to an RFE, as I think it's worth discussion at least.

Comment 5

[Chris Lawson (gone)]

If the UA has been spoofed, it can easily be looked up in about:config.

If the UA has *not* been spoofed, then the only information that anyone could possibly have use for is the build ID, which is already in the About box.

As far as I'm concerned, for those reasons and for the reasons mentioned in comment 1 and comment 2, this is a WONTFIX due to being incredibly time-consuming for virtually zero benefit.

cl

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think this is WONTFIX.  Most people don't care what that information is and don't ever need to see it (and if the existing build ID weren't useful for QA purposes and otherwise inacessible, I'd argue that it should be removed altogether from that dialogue).

If you really need to see the UA string in the browser without accessing any other sites, add this bookmarklet to your bookmarks bar/menu:

javascript:document.write(navigator.userAgent)

Comment 7

[David E. Ross]

No one has yet explained why this bug is either Invalid or Wontfix, while bug #230182 (which addresses the same problem in Thunderbird) is Assigned to be fixed.  

See the original Description for why this bug was written (a Web site rejected Camino as a browser).  I'm NOT a Camino user.  My daughter is.  Although my daughter is known as an expert in instructional technology and Web instruction, she knows nothing about bookmarklets and little of JavaScript.  I submitted this bug report because I felt the Build Identifier at the top of the Description was inadequate, but that was the best my daughter could provide.  (Compare the Build Identifier with the User-Agent, which I can get from About SeaMonkey.)  

I'm not changing the status of this bug.  If you still think the Build Identifier is adequate, so be it.  But please address the issue at the top of this comment (Camino vs Thunderbird).  

Comment 8

[Samuel Sidler (old account; do not CC)]

David, I'm unclear as to why you think a build identifier is not adequate. Build identifiers give us the date a build was made and which branch it was made from. That allows us (meaning: bug triagers, contributors, and developers) to easily determine the UA string.

From "Version 2006021400 (1.0)", I can easily gather that she was running Camino 1.0 final, which was built on February 14th of this year off the Mozilla 1.8.0 branch. That seems to be enough information. What more does the UA string give you that is needed?

Comment 9

[David E. Ross]

My SeaMonkey UA string identifies not only the build date and branch but also the version of the operating system (Windows 98) and the localization (en-US).  In my case, it also identifies one of the extensions I added (Mnenhy/0.7.4.0).  All of these might be important during diagnosis and correction of a bug, if not during triage.  

I realize that Camino is only for Mac platforms.  But I had to guess Mac OS X 10.4 as the version my daughter's operating system.  I have no idea whether, living in Canada, she is using the en-US localization of Camino.  (If she were using Firefox and Thunderbird, she might indeed be using the en-GB localization (and spell it "localisation"); I don't know if en-GB exists for Camino.)  She was not immediately available to give me this information since she lives two times zones and an international border away from me.  

All this would be revealed by a complete UA string.  

Comment 10

[Samuel Sidler (old account; do not CC)]

(In reply to comment #9)
> My SeaMonkey UA string identifies not only the build date and branch but also
> the version of the operating system (Windows 98) and the localization (en-US). 
> In my case, it also identifies one of the extensions I added (Mnenhy/0.7.4.0). 
> All of these might be important during diagnosis and correction of a bug, if
> not during triage.  

UA strings don't specify which version of OS X they're running. In addition, extensions are relevant to Camino and, in my opinion, shouldn't be changing the UA string of SeaMonkey either.

As far as the localization, we don't currently list the localization in our UA string (see bug 331576). We do, however, list MultiLang (or is it just "ML"?) at the end of a UA string if it's the multilingual release. The localization isn't really relevant for most Camino things, however, unless the user is reporting an bug in the translation and then they normally know what language they're in. Camino 1l0n is almost identical to Camino English. (There have been a few excetions of this, but they're few and far between.)

I still don't see a compelling argument to add the UA string to our About window, especially with the amount of work it could be to roll our own.

Comment 11

[Samuel Sidler (old account; do not CC)]

(In reply to comment #10)
> extensions are relevant to Camino and, in my opinion, shouldn't be changing the

And by "are", I meant "aren't".