Closed Bug 80735 Opened 24 years ago Closed 23 years ago

Build id in window title lowers usability

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: hsivonen, Assigned: mpt)

References

Details

Attachments

(2 files, 1 obsolete file)

Titles of windows displaying distinct pages as seen in WindowMaker
2.46 KB, image/png
Details
shell script
1.78 KB, text/plain
Details
The build id in the window title lowers usablility by being distracting. For example, in a list of open windows, a considerable amout of characters don't actually describe the page loaded in the windows. However, the situation is even more annoying, if the window names are shortened from the middle as in WindowMaker. In such a case, useful information actually gets displaced by less relevant duplicate strings. Obviously, the idea is to make sure that anyone can find the build id. Since it is quite normal that the app version is available in the about box, could people be expected to find the build id there? Another idea I can come up with is displaying the build id as a dummy [possibly an alias for About Mozilla] menu item in the QA menu. (Putting the build id in the status bar would be bad, too, since status bar real estate is needed for other purposes.)
True. But at this stage of development, it is still quite likely that you won't be able to see the version number in the About box at all. The About box may refuse to open, or it may open but have no content, or the content may be there but the version number may be cropped by the edge of the non-resizable window, or the relevant item in the `Help' menu may be completely missing, or ... Perhaps this could be something that gets turned off for milestones, but left on for nightlies. We could turn off the `Debug' and `QA' menus in milestones by the same mechanism.
Could at least the strings "- Mozilla {Build id: " and "}" be removed to reduce the number of extra chars? (Posted with FizzillaCFM build 0000000000. :-)
I'd be willing to remove "{Build id: " and "}"
*** Bug 91850 has been marked as a duplicate of this bug. ***
see also bug 61841 ....
Unduping my bug, 91850. It is a 4xp issue for striping the info in the Tasks menu.
I'd also like to suggest that the build ID would be better on the status bar than the title bar if you must put it somewhere other than the About box.
um, see mpt's comment. the status bar may be horribly broken or unviewable and is certainly not always visible, whereas any normal window manager can give you the window title.
I will block any attempt to remove the build ID from the Mozilla titlebar. These builds are provided for development and testing purposes. If you don't want an ID in the titlebar then build your own and hack that out or use an actual distribution like Netscape 6.x or Beonex. This bug should be Resolved as WONTFIX.
Actually if you build from source, the title bar date is correct only if you build it from scratch every day. If you do daily update thereafter, the title bar date always shows {Build ID: 0000000000}. Also the User-Agent string date never gets updated from the date on which you built it.
set BUILD_OFFICIAL=1 should get updated numbers.
> set BUILD_OFFICIAL=1 should get updated numbers. Sounds easy until you read: http://www.mozilla.org/build/distribution.html and Bug 27316. (Do we need splitsym.exe on Win? Where do we get one?. etc.)
afaik splitsym is for talkback. i don't (can't) build talkback ...
Asa says WONTFIX. Gerv
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
rs vrfy asa's decision
Status: RESOLVED → VERIFIED
See also bug 56995, "Application name should not be included in window title".
*** Bug 107692 has been marked as a duplicate of this bug. ***
Sigh. Great. Useless crap in the title bar forever. Sometimes I wonder why I bother with this project.
*** Bug 141144 has been marked as a duplicate of this bug. ***
Asa, can you elaborate on your position? It sounds like you're saying, "if you want a usability enhancement, go elsewhere". Why does having the build id in the titlebar help "development and testing" more than putting it in the About box? Why can't it be an option for those who want it, given that I expect most users find it merely noise? Finally, can someone point me to where in the sources, or better yet in the compiled binaries, I can find the build id string? I tried some simple grepping but had no luck.
> Finally, can someone point me to where in the sources, or better > yet in the compiled binaries, I can find the build id string? The file to edit is locale/en-US/navigator/navigator-title.dtd in en-US.jar. It is also easy to fix bug 56995 in your personal copy while you are at it. (The debug and QA menus can be removed by editing content/navigator/navigatorOverlay.xul in comm.jar.)
answering why asa and others don't want to rely on the about dialog box is easy. if mozilla hangs before you can get there, then while it's nice to tell people to use the about box to get the build info, but it's also useless, since they can't get there. the window title is something which barring serious catastrophe is always accessible to users. if that catastrophe does happen, then we do have recourse, but it's not a big deal because when it happens we'd get enough reports right away so we could very easily track down which builds have the problem. -- and ideally this catastrophe should never reach cvs because the precheckin tests really should prevent it.
An even better method might be to include the Build ID in the version string shown in the filesystem. For example, where I now see 1.0.0, I could see 1.0.0 (2002052305). That would enable users to know the build even if the application couldn't launch.
except that means that we'd have to do something really stupid to our build system. if the library from yesterday hasn't changed in today's build, we'd still have to update the timestamp and change the binary bits just to have the new build id in each library and application. yes, it's an interesting theory, but it doesn't really work well.
Changes the string in the window title from "Mozilla (Build ID NNNNNNN)" to "Moz". On FreeBSD you can drop this patch in /usr/ports/www/mozilla/files and it will get picked up automatically when you rebuild.
Attachment #85184 - Attachment description: Patch to change window title to "Moz" → Hack to change window title to "Moz"
Attachment #85184 - Attachment is obsolete: true
Timeless, is there any way the build system could be modified or improved to make such a change more feasible? Perhaps I should open an RFE bug for it.
If I could have imagined a way to make it work, I'd have made the suggestion earlier. It's possible that I have made a suggestion somewhere, but I can't offhand think of a good solution or remember if I did. Essentially you're stuck because you have a many to many mapping and it's unclear what in the world the point is. one approach would be to just include a filelisting indicating the datestamps for all files used to build mozilla and the libraries to which they contributed. Such a file would always be new, but it would at least give you some information. The problem is generating such a file in a useful fassion might be an expensive cvs operation, and wouldn't be useful to 99.9999% of users. I think had I made a suggestion it would have been to version the layout and networking libraries since they're the ones which actually care about build ids. But if we actually did that, could you explain to a user how to get version info for some library that wasn't mozilla.exe? Oh, the other approach is to just explain to users how to extract the file from the archive to report their build id. the problem here is that I don't want to explain to some user how to do it. Anything that the user can't see the moment the program runs doesn't work. Asa would probably argue rightfully so that sticking it in version info while sensible to an advanced user is utterly useless to the target audience. If you want to make a build config suggestion, suggest that they include the build id as a file named buildid.txt or something. but keep in mind that this is totally useless, not guaranteed to work, and won't address anyone's concerns but your own. - And of course if you can't address Asa's concerns (and you can't) then there's really no point. -- Note that any build change will make the archive bigger, for no real use, and someone should fight you over it :-)
Timeless, thanks for the response. I filed bug 147456 to give the notion its' own visibility. (Could be worse. At least I'm not suggesting bug 142075. Yikes.)
timeless, The build system could put a zero-length file with the build id as the name in the dist directory. Anyway, the presence of the build ID and the QA & Debug menus make me a less good QA volunteern. I'm less motivated to update to a newer nightly, because of the time it takes to remove those items from the UI each time. BTW, why don't the trunk nighlies and 1.0 have the build ID stuff in the same place? 1.0 has the title bar stuff in a separate DTD file that is easier to replace. The trunk nightlies have the title bar stuff inside navigator.dtd. (Or why does 1.0 have a build ID at all?)
Attached file shell script —
I've attached a shell script to this bug just so people looking for this can find it. I wrote it because I download nightlies a lot and I just wanted something I could run and it would make the changes for me. You also get New Navigator Window and New Tab as first-level menuitems as an added bonus. Anybody find this interesting, let me know.
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: