Closed Bug 80735 Opened 23 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: