56995 - Application name should not be included in window title

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[Matthew T (active 1999-2002)]

Attachment: testcase

Comment 2

[Blake Ross]

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.

Comment 3

[Blake Ross]

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.

Comment 4

[Matthew T (active 1999-2002)]

[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.

Comment 5

[Blake Ross]

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?)

Comment 6

[Henri Sivonen (:hsivonen)]

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.

Comment 7

[Tobias Burnus]

How about making it a preferences?

Comment 8

[Blake Ross]

I will shoot myself if you make this a preference.

Comment 9

[timeless]

For now i'm marking this as mac only.

Comments?

Comment 10

[Matthew T (active 1999-2002)]

*sigh*

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

Comment 11

[sairuh (rarely reading bugmail)]

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...

Comment 12

[Akkana Peck]

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.

Comment 13

[Blake Ross]

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

Comment 14

[J Luh]

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?

Comment 15

[Andrew Thompson]

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.

Comment 16

[Jesse Ruderman]

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

Comment 17

[Matthew T (active 1999-2002)]

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

Comment 18

[Greg K.]

Nominating for Mozilla 1.0.

Comment 19

[Henri Sivonen (:hsivonen)]

Attachment: Quick fix I use myself

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.

Comment 20

[Jeremy M. Dolan]

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.

Comment 21

[Henri Sivonen (:hsivonen)]

Attachment: Patch for making it a pref

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.

Comment 22

[Henri Sivonen (:hsivonen)]

..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.

Comment 23

[Andrew Thompson]

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).

Comment 24

[Andrew Thompson]

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... 

Comment 25

[Greg K.]

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

Comment 26

[Andrew Thompson]

Attachment: new patch addresses most concerns

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.

Comment 27

[Greg K.]

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.

Comment 28

[Andrew Thompson]

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.

Comment 29

[Andrew Thompson]

Attachment: Fixes the hyphenation issue

Comment 30

[Andrew Thompson]

Attachment: Removes "- Mozilla" on Mac OS. Moves the buildid into the menubar

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.

Comment 31

[Greg K.]

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?)

Comment 32

[Jeremy M. Dolan]

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.

Comment 33

[Henri Sivonen (:hsivonen)]

> 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.

Comment 34

[timeless]

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]

Comment 35

[Henri Sivonen (:hsivonen)]

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?

Comment 36

[timeless]

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 :)

Comment 37

[J Luh]

[change keyword since Mozilla 1.1 has already been released]

Comment 38

[J Luh]

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

Comment 39

[Rafael Ebron (:rebron)]

adt:nsbeta1-

Comment 40

[louis bennett]

Attachment: patch to fix windows and tabs based on pref

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.

Comment 41

[louis bennett]

taking

Comment 42

[henning schild]

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. 

Comment 43

[Greg K.]

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

Comment 44

[Serge Gautherie (:sgautherie)]

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

Comment 45

[Stefan [:stefanh]]

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

Comment 46

[Stefan [:stefanh]]

Attachment: Patch for mailNews

Just attaching a patch for mailNews.

Comment 47

[Stefan [:stefanh]]

Attachment: Remove appName from viewPartialSource.xul (pushed)

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.

Comment 48

[[e-mail]]

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!)

Comment 49

[Stefan [:stefanh]]

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

Pushed this to comm-central as changeset 2421d18c3a24.

Comment 50

[Stefan [:stefanh]]

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

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

Comment 51

[Stefan [:stefanh]]

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

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

Comment 52

[Karsten Düsterloh]

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

Looks sane (for Mac at least).

Comment 53

[Stefan [:stefanh]]

Attachment: New version without ifdef'ing (pushed)

Comment 54

[Stefan [:stefanh]]

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.

Comment 55

[Stefan [:stefanh]]

I fixed the browser in bug 457548.