Matthew T (active 1999-2002) Reporter
	Description • 24 years ago

To reproduce:
* Open the attached testcase.
* Look at the title bar.

What you should see:
* `Public enemy number one'.

What you actually see:
* `Public enemy number one - Mozilla'.

Advertising the name of the program in the title bar is completely redundant, since:
* it gives the impression that the application is just a visitor on the user's
  system (cf. file managers, which don't include `Windows Explorer' or `Finder'
  in the titles of their folder windows);
* on Mac OS, the name of the application is visible in the application menu
  anyway;
* in all Mozilla applications, the title bar is already used for other things,
  which are usually quite long to begin with (e.g. Web page titles, message
  subject lines);
* this is an open-source project, and as such should not subject users to
  constant advertising for a program they are already running.

Occurs with:
* Build 2000101620, Mac OS 9.0

Does not occur with:
* any other document-based application I have ever seen on the Mac, except
  for previous versions of Mozilla.

This bug will depend on other bugs which make sure that the window title always
has some content.

	Blake Ross
	Comment 2 • 24 years ago

I disagree that the appname should not be appended to the page title in 
Windows.  Every application I've ever used has had its name in the titlebar, 
and it would be quite odd if, for example, a page had `Microsoft Internet 
Explorer' as its title and that's all we put in the titlebar.  This should be 
mac-only, and maybe linux as well.

	Blake Ross
	Comment 3 • 24 years ago

Two other points, in response to yours:
* I don't see the name in the titlebar as `advertising', and I don't think too 
many other users would either.  Why are we advertising a product they're 
already using?  I think of it more as program identification, a quick reference 
to the app name without a visit to the about dialog.
* Windows Explorer does not just give directory or file information in the 
titlebar, it is prepended by "Exploring -".  It doesn't need really need to say 
the full `Windows Explorer' because the user thinks of it as another integrated 
part of Windows (as indicated by its interface's conformance to the rest of the 
OS UI, and lack of a specific about box -- it just uses the global Windows 
one), and it's really not a separate application.

	Matthew T (active 1999-2002) Reporter
	Comment 4 • 24 years ago

[Third attempt at entering this ...]

Adding dependency: This bug needs to be fixed before bug 36305 (proxy icon in
title bar) will make sense from a UI perspective.

Response to Blake's points:

> Every application I've ever used has had its name in the titlebar

The latest version of MSN Explorer for Windows doesn't, it just has the title of
the page. The start of a trend? I certainly hope so.

> it would be quite odd if, for example, a page had `Microsoft Internet
> Explorer' as its title and that's all we put in the titlebar

Maybe, but there is much less scope for that kind of titlebar pratfall than
there is scope for the kind of titlebar pratfall shown by my testcase.

> Why are we advertising a product they're already using?

Exactly.

> I think of it more as program identification, a quick reference to the app
> name

In an ideal world, users do not need to care which app they are using. This is
an almost completely painless step towards that ideal world. If a user needs to
know which app they are using, they can use the About box. (In such cases
they'll likely need to know the version number too, information which the title
bar will normally not provide anyway.) There is no need to clutter their display
with the app name all of the rest of the time, when they do not need to see it.

> Windows Explorer does not just give directory or file information in the
> titlebar, it is prepended by "Exploring -".

In the normal case, where you double-click on a disk or folder icon on your
desktop, this is not true; only the folder name is shown. `Exploring -'
indicates a particular view mode of Windows Explorer, in the same way that an
app might append `(Read-Only)' to the title. It is not really anything to do
with the app name.

> the user thinks of it as another integrated part of Windows

Exactly. That's what we should be aiming for -- an interface which the user does
not notice, because it just blends in with the rest of the system.

	Blake Ross
	Comment 5 • 24 years ago

I asked why we'd be advertising a product they're already using to (hopefully) 
show that the user doesn't think we are, not to prove the point that we 
shouldn't be.  In most (if not all) other non-Internet-related applications, 
the `title' in `titlebar' is the app title; not <title>bar.  We would be 
redefining the role of the titlebar if we did this.

When you double click on a folder, what appears is just a window showing the 
folder contents.  This isn't really a separate application, and I think it's to 
the user that they aren't launching a new application when they do that.

We don't currently blend in with the system at all, and I think some other 
changes would have to be made to make the app integrate more before we do this, 
if that's our goal.  Personally, I think a better justification for doing this 
would be to unify the browser chrome and the webpage (which, iirc, was one of 
the original goals pf the product).  In other words, the browser chrome would 
just be extended navigation of the webpage displayed in the content area, and 
thus it would make sense to only display the webpage title in the titlebar, 
because the user thinks he's looking at one entity -- a webpage.  But we're 
really nowhere near this full integration (and I'm not sure that we're even 
headed in that direction - are we still trying to design the chrome according 
to web look and feel?)

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 6 • 24 years ago

On the Mac (at least) the title bar should only contain the document title--regardless of 

whether Mozilla is considered app-centric or document-centric.

	Tobias Burnus
	Comment 7 • 24 years ago

How about making it a preferences?

	Blake Ross
	Comment 8 • 24 years ago

I will shoot myself if you make this a preference.

	timeless
	Comment 9 • 24 years ago

For now i'm marking this as mac only.

Comments?

	Matthew T (active 1999-2002) Reporter
	Comment 10 • 24 years ago

*sigh*

Ok, Mac only then. But I predict you'll be doing this on Windows too within 
three years. :-)

	sairuh (rarely reading bugmail)
	Comment 11 • 24 years ago

akkana, d'you think the application name should be in the titlebar of unix
mozilla/n6 windows? since i prefer less clutter in general, i wouldn't mind it
going away. but i don't have strong feelings about this...

	Akkana Peck
	Comment 12 • 24 years ago

Not that big a deal to me really, but since you asked:

I like having the name of the app in the titlebar: I don't actually care that
it's in the titlebar itself (if I can see the titlebar, I can see the window and
figure out what app it is) but that also makes it show up in the application
list as a Mozilla or Netscape window.  When I'm choosing from a long list of
minimized windows trying to find my browser window, it can be quite difficult if
the window is listed as "Files" or "My page" or " " (blank) or other such titles
one commonly sees on the web.

	Blake Ross
	Comment 13 • 24 years ago

I think Matthew is a man before his time.  -> Future, maybe I'll look into this 
for mac at some point.

	J Luh
	Comment 14 • 23 years ago

Looks like there is pretty strong agreement that at least on the Mac, the
application name should not appear in the window title. Shouldn't this be a
pretty easy code change to make?

	Andrew Thompson
	Comment 15 • 23 years ago

This is assembled here:

http://lxr.mozilla.org/mozilla/source/xpfe/appshell/src/
nsContentTreeOwner.cpp#567

but unfortunately we can't just #ifdef XP_MAC in this file, we'd need to fix it 
in the DTDs and in general these are locale specific and not plaform specific 
everywhere.

	Jesse Ruderman
	Comment 16 • 23 years ago

See also bug 80735, "Build id in window title lowers usability".

	Matthew T (active 1999-2002) Reporter
	Comment 17 • 23 years ago

*** Bug 107695 has been marked as a duplicate of this bug. ***

	Greg K.
	Comment 18 • 23 years ago

Nominating for Mozilla 1.0.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 19 • 23 years ago

I attached a quick patch that works for me and removes 33 chars from the title.
I don't expect this to be checked in. I'm just attaching it in case someone
wants to use it in a personal build and doesn't want to search for the right
source line to zap.

	Jeremy M. Dolan
	Comment 20 • 23 years ago

From the comments in this, and bug 80735, it becomes obvious this is a personal
preferance. So why not a pref that would be OFF by default (for the reasons
stated in 80735), which would remove " - Mozilla {Build ID: XXXXXXXXXX}" from
the title?

Also, I don't feel this depends on 56993, as a blank title isn't the end of the
world.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 21 • 23 years ago

I'm attaching a patch for making this a pref. With the pref set the effect is
the same as with attachment 57300 [details] [diff] [review] on the Mac but with the pref service
overhead.

Both patches zap both " - Mozilla" and the build id. However, the build ID is
still available on about:blank. If you want either patch to go in, you'll need
to convince Asa and MPT that build ID on about:blank is enough. 

I'd prefer attachment 57300 [details] [diff] [review] which just zaps the extra stuff on the Mac and
doesn't access the pref service.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 22 • 23 years ago

..or rather, I'd prefer zapping " - Mozilla" and the build ID on other
platforms, too. I don't like the extra stuff on Linux and Solaris, either.

	Andrew Thompson
	Comment 23 • 23 years ago

smfr (or one of the other super reviewers, but I think it was him) told me #ifdef 
XP_MAC is not acceptable in that file ... so the pref thing is probably better. 

I think this is probably called quite a lot (this is a guess), so I'm not 
convinced its a great idea to read from the prefs service every time.

The two ways of fixing that would be to use an instance variable, or something 
like the admitedly ugly local static approach

static bool needToGetPref = true
static bool userWantsTitle = true

if (!needToGetPref){
	userWantsTitle = pref service lookup ...
	needToGetPref = false;
}

The instance variable approach is much cleaner, naturally it should actually be a 
class variable (static) if its the same for all windows...

Come up with a fix to that stuff and I will r=.

(obviously we can make this platform specific by setting the pref to different 
defaults on each platform. If you go that route, you need to include that in the 
patch too).

	Andrew Thompson
	Comment 24 • 23 years ago

I just measured henri's patch. Using a pref takes ~1 tick (this is Mac OS 10, on 
a G4 400mhz) and its called twice every time we open a window. I'm not sure 
exactly what the ticksize is on mac os x, but its either 1 millisecond or less.

So ignore my earlier comment.

That said, aparently Asa will block any patch which removes the build id from the 
title bar, so we'll have to change the DTDs. sigh... 

	Greg K.
	Comment 25 • 23 years ago

Must...resist...making a...derisory...comment...

	Andrew Thompson
	Comment 26 • 23 years ago

This patch builds on Henri's. It makes it a pref, turns that pref on only on
Mac OS (so all other platforms keep "Mozilla" or "Netscape" in the name.

It also *preserves* the buildid in the titlebar in Mozilla builds, regardless
of the setting of the pref on any given platform.

Obviously in commercial Netscape builds, we get the desired effect, which is
the window title is the document title with no embelishments.

Everyone satisfied? If you want to flip the pref on Linux/Windows, please argue
about that somewhere other than this bug.

	Greg K.
	Comment 27 • 23 years ago

LordPixel, does the pref also turn off the titlemodifiermenuseparator (" - ")
from displaying if the buildName is turned off? It should, since the buildID
will already be "seperated" by the curly brackets.

Also, be sure this takes effect on Mac OS X as well.

	Andrew Thompson
	Comment 28 • 23 years ago

Yes, I noticed the problem with the hyphen this morning. I'll fix the patch later 
when I have more time.

Also, I test on mac os x first.

	Andrew Thompson
	Comment 30 • 23 years ago

Alternative solution

1/ remove "- Mozilla" on Mac OS only

2/ move "{buildid: XXXXXXXXXXXX}" into the menubar on all platforms.

I add it to the name of "Debug" menu, so the menu is called "Debug {buildid:
XXXXXXXXXX}"

This is highly visible, and it means Moz has nice window titles on Mac OS.

Came up with this idea chatting to timeless earlier today.

	Greg K.
	Comment 31 • 22 years ago

Nominating for Mozilla 1.1. Can we get this patch reviewed and into the beta, or
does it need to wait for 1.2?

(Does this really depend on bug 56993?)

	Jeremy M. Dolan
	Comment 32 • 22 years ago

What if I have an "IE" skin for Mozilla, and the same page loaded in Moz and
IE... how do I tell which application is which?

What other application doesn't name themselves in the window title? That's what
it's *for*. Document <title> is secondary.

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 33 • 22 years ago

> What if I have an "IE" skin for Mozilla, and the same page loaded in Moz 
> and IE... how do I tell which application is which?

- Doctor, doctor, it hurts when I do this!
- Don't do it then.

It is silly that Mozilla should include additional cruft in the title bar in
order to let users of an IE theme distinguish between Mozilla and IE. If you
want then to be distinguishable, don't use a theme that makes them
indistinguishable. Like, duh.

> What other application doesn't name themselves in the window title? 
> That's what it's *for*.

I'm guessing you are a Windows user. 

Opera 6 doesn't show the app name in the title bar when run in the SDI mode on
Windows XP. I can distinguish between Mozilla, Opera and IE because their UIs
aren't identical and they all have distinct icons in the top left corder of the
windows and in the Taskbar.

On the Classic Mac OS and on Mac OS X, Netscape and Mozilla are the only apps
whose windows have the app name in the title bar even though there is a document
title. So how do I know which app I'm looking at? First of all, apps don't look
exactly *identical*, even though they are supposed to look *similar* to each
other. Secondly, the app name is displayed in the menu bar (which is the
platform convention). When I'm looking at the window listings in the Dock, the
window titles are grouped by app, so including the app name in the window titles
is useless and adds clutter.

In the GTK/Gnome world, things are usually less consistent than on Mac. A quick
sampling shows that there are apps that don't include the app name in document
windows and then there are those that do. The GIMP and Dia (whose accessory
windows could be considered relatively Mac-like) don't have the app name in the
title bar of document windows. Gnumeric and AbiWord (whose UI design could be
considered more Windows-like) have the app name in the title bar. It is worth
noting, though, that AbiWord also exists on Windows and that might affect the
UI. Galeon has the app name in the title bar, but that could be considered to be
just Mozilla influence. 

Again, the fact that the UIs of different apps aren't identical, even though
they are similar, is enough for me to figure out which app I'm looking at. When
the window titles show up in the Gnome Panel, they are prefixed with distinct
icons that let me know which app they belong to.

	timeless
	Comment 34 • 22 years ago

in the future, mozilla and ie will probably both put site icons into the system 
menu instead of app/document icons, this means that the visual queue you 
suggest will be gone.

mpt suggests that users won't, don't and shouldn't care which app is doing the 
rendering.

that's certainly one view. if you want to know which is doing it, then 
help>about (windows) will tell you. [for MacOS you'd just check the multifinder 
area, and for MacOSX you'd check the app menu]

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 35 • 22 years ago

Konqueror put a favicon in Gnome Panel. I didn't like it.

Which icon would you use when the Taskbar on Windows XP or the Gnome Panel
groups Mozilla windows?

	timeless
	Comment 36 • 22 years ago

app icon, which would probably be a lizard/raptor/M. but you really don't want 
to think about this (this is partially an unsettled legal issue) as it's 
probably the job of that app (taskbar/panel) to pick the icon, i don't think 
there's an attribute they look for. -- I could be wrong in which case you 
should definitely correct me :)

	J Luh
	Comment 37 • 22 years ago

[change keyword since Mozilla 1.1 has already been released]

	J Luh
	Comment 38 • 22 years ago

What is the status of this patch? Is it still up to date? Will it make it into
mozilla1.2?

	Rafael Ebron (:rebron)
	Comment 39 • 21 years ago

adt:nsbeta1-

	louis bennett
	Comment 40 • 21 years ago

this is a patch to remove " - Mozilla" from the titlebar on the mac, based on
attachment 62648 [details] [diff] [review]. i didn't look at moving the build id to the debug or QA menu,
because that's a wee bit beyond my current knowledge of mozilla. (-:

suggestions / revisions would be appreciated. thanks.

	louis bennett
	Comment 41 • 21 years ago

taking

	henning schild
	Comment 42 • 21 years ago

i didn't read all of this, but it seemed to me that people are only talking 
about advertisement. i think i've got an interresting point to add. 
i have a mouse with 2 thumbbuttons and i'm using imwheel to make them work as 
"back" and "forward" keys. imwheel translates the 6th and 7th mousebutton to 
another event depending on the window title that the mouse action happend on. 
so i vote for the Mozilla in the title. 

	Greg K.
	Comment 43 • 20 years ago

, or patch review? Both Seamonkey and FF continue to lack the application icon
on window titlebars on Mac (bug 107695 duped to this).

	Serge Gautherie (:sgautherie)
	Comment 44 • 16 years ago

Filter "spam" on "guifeatures-nobody-20080610".

	Stefan [:stefanh] Assignee
	Comment 45 • 16 years ago

I'll do mailNews et al once bug 457548 is resolved.

	Stefan [:stefanh] Assignee
	Comment 46 • 16 years ago

Just attaching a patch for mailNews.

	Stefan [:stefanh] Assignee
	Comment 47 • 16 years ago

Neil, are you OK with this? Afaics, this is the only window (that isn't a "main" window) that has "- SeaMonkey" appended to the title. My idea is that in order to be consistent with the other windows win/nix should be happy with this change too.

	neil@parkwaycc.co.uk
	Comment 48 • 16 years ago

Comment on attachment 355846 [details] [diff] [review]
Remove appName from viewPartialSource.xul (pushed)

I guess this is OK. (Regular view source does have a - SeaMonkey, but then again you can even browse in it these days!)

	Stefan [:stefanh] Assignee
	Comment 49 • 16 years ago

Comment on attachment 355846 [details] [diff] [review]
Remove appName from viewPartialSource.xul (pushed)

Pushed this to comm-central as changeset 2421d18c3a24.

	Stefan [:stefanh] Assignee
	Comment 50 • 16 years ago

Comment on attachment 344144 [details] [diff] [review]
Patch for mailNews

I think we can do this now, after this it's onlt browser left.

	Stefan [:stefanh] Assignee
	Comment 51 • 16 years ago

Comment on attachment 344144 [details] [diff] [review]
Patch for mailNews

(This is identical to how Thunderbird does it, btw)

	Karsten Düsterloh
	Comment 52 • 16 years ago

Comment on attachment 344144 [details] [diff] [review]
Patch for mailNews

Looks sane (for Mac at least).

	Stefan [:stefanh] Assignee
	Comment 54 • 16 years ago

Comment on attachment 357723 [details] [diff] [review]
New version without ifdef'ing (pushed)

Pushed this as changeset ef7223d5becb. I'll leave this open until browser windows are fixed.

	Stefan [:stefanh] Assignee
	Comment 55 • 15 years ago

I fixed the browser in bug 457548.