194306 - Take "mozilla" and "build id" out of WM_NAME and WM_ICON_NAME

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect)

Description

[Jamie Zawinski]

It is arguably useful for the window's *title* to have the word "Mozilla" in it.

I can understand why developers might find it useful to have the build ID there,
but most people don't care (and when they do, they can select Help/About Mozilla.)

But I can't see any reason to have " - Mozilla {Build ID: 2003021120}" be
appended to both the WM_NAME and WM_ICON_NAME properties.  I really don't need
to see that in my tasklist's popup menus and my window manager's window list. 
It just makes the menu wider and cluttered.  You should put only the document
title there.


Mozilla 1.3b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211
Red Hat Linux release 8.0 (Psyche)

Comment 1

[Jamie Zawinski]

(Just in case it's not clear to whoever's reading this: keep in mind that the
window title, the WM_NAME prop, and the WM_ICON_NAME prop, and the WM_CLASS prop
are four totally different things with different functions.)

Comment 2

[Boris Zbarsky [:bzbarsky]]

to blizzard

Comment 3

[Geoff Leach]

I agree most people dont care about the (ten digit) build id. And that it adds
to width and clutter. I build Mozilla to get SVG and my build id is (always)
"0000000000" which I dont need to look up at all!

I havent seen any discussion as to why the build id was put in the title
originally, perhaps useful when Mozilla's user base was mainly developers
(<1.0?) . Bugzilla now uses the user agent string as the build id, and about:
also shows the user agent string, so the (10 digit) build id is kind of submerged. 

However, I would like to see "Mozilla 1.3b" or "Mozilla 1.3b+" (where 1.3b is
the part of the user agent string after "rv:") or similar in the window title,
rather than just "Mozilla". I see it as a form of advertising or evangalism.
Actually, thinking about it, I would much rather see the "rv:" version in the
window title than the build id...

Comment 4

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 5

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420