tracking bug for tab title changing to/becoming "(Untitled)"

VERIFIED FIXED in mozilla1.0.1


Tabbed Browser
16 years ago
10 years ago


(Reporter: Dave, Assigned: Christopher Aillon (sabbatical, not receiving bugmail))



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2 RTM][vrfy'd bugs w/trunk builds])


(1 attachment)



16 years ago
There are many open bugs of the form "tab title changes to (Untitled) <under
some circumstances> [even though it shouldn't]".  I am creating this bug to
track those issues, and to make it easier for people filing bugs on that subject
to find out if their case has already been addressed.  I hope it will also help
make it more obvious which (if any) of these related bugs may be duplicates of
one another, and whether there may be even more sub-cases yet to be addressed.
- I think this should avoid becoming a forum for discussing what should be
displayed for the title in a tab when there is no title specified in the HTML
source.  Many people opine that "(Untitled)" is not a very good substitute.  But
even if the tab's title for untitled documents were something other than
"(Untitled)", these issues would still be a problem.  See Bug 111880.
- Although Bug 111118 already exists with a very generic summary on this topic,
it does not serve as a tracking bug, and I'm not going to wait around for it to
be morphed into one.  Anyway, its dicussion is a case in point of why a tracking
bug is useful for this issue:  "Isn't this a dupe of x?" "No, sounds more like
similar bug y." "Well, I find bugs u, v, w, x, y, z that all sound like this
one."  Not to mention the comments of the type, "I'm seeing this behavior <in
some case>, does that fall under this bug?"
I don't know if it's proper for regular users to file tracking bugs.  If the
component owner or someone else is upset that I am filing a tracking bug, then
please invalidate it (and, I guess, remove the dependencies).  No hard feelings.
 In the meantime, ...

Comment 1

16 years ago
Adding dependencies.
Another note:  in addition to Bug 111880, see also Bug 144431 for discussion of
what to do instead of "(Untitled)".  (As I said, this bug is not intended to
depend on those.)
OS: Windows 98 → All
Ever confirmed: true
Keywords: meta

Comment 2

16 years ago
Attachment 71310 [details] [diff] would fix all of the dependencies at time of writing, except
that it has bitrotted, so I'll attach a new patch here.

Comment 3

16 years ago
Added bug 101831 to dependency list.
Depends on: 101831


16 years ago
No longer depends on: 151372
Created attachment 92187 [details] [diff] [review]
Patch v.1.1

Built off my patch from bug 108350, I decided to upload the new patch here
because it fixes all the dependencies as well.
Assignee: jaggernaut → caillon
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1
Nav triage team: this is a low risk patch, which I've tested to fix all
dependent bugs.  It is high visibility; users are likely to encounter this bug
since it has quite a few ways to be triggered (as can be seen by visiting bugs
on the dependency tree of this one).  Jag and I talked about it and we would
like to try and get this fix in for Mach V.

Comment 7

16 years ago
Comment on attachment 92187 [details] [diff] [review]
Patch v.1.1

>Index: xpfe/global/resources/content/bindings/tabbrowser.xml
>RCS file: /cvsroot/mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml,v
>retrieving revision 1.55
>diff -u -r1.55 tabbrowser.xml
>--- xpfe/global/resources/content/bindings/tabbrowser.xml	21 Jul 2002 01:48:34 -0000	1.55
>+++ xpfe/global/resources/content/bindings/tabbrowser.xml	22 Jul 2002 03:30:29 -0000
>@@ -213,10 +213,11 @@
>+                if (this.mTab.label == this.mTabBrowser.mStringBundle.getString("tabs.loading")) {
>+                  this.mTabBrowser.setTabTitle(this.mTab);
>+                }

Try to stay within the file's style of not having {} for single line bodies.

>                 if (this.mTabBrowser.mCurrentTab == this.mTab)
>                   this.mTabBrowser.mIsBusy = false;
>               }
>@@ -529,15 +530,39 @@
>             var tabBrowser = this.parentNode.parentNode.parentNode;
>             var tab = tabBrowser.mTabContainer.childNodes[i];
>-            if (this.contentDocument.title)
>-              tab.setAttribute("label", this.contentDocument.title);
>+            tabBrowser.setTabTitle(tab);

You could inline |tab| here since there's only one use left.

>+      <method name="setTabTitle">
>+        <parameter name="aTab"/>
>+        <body>
>+          <![CDATA[


>+            else {
>+              title = this.mStringBundle.getString("tabs.untitled");
>+            }

Same applies here for a single line body

sr=jag (inlining |tab| is up to you, other two nits I'd like to see fixed)
Attachment #92187 - Flags: superreview+

Comment 9

16 years ago
Comment on attachment 92187 [details] [diff] [review]
Patch v.1.1

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #92187 - Flags: approval+
Checked in on the trunk.
caillon, did you check in something else than this patch?
At least the current setTabTitle-method looks different.

I think we should not use the whole URI (currentURI.spec) as a
title on tabs in some cases
but only the filename 
(currentURI.QueryInterface(Components.interfaces.nsIURL).fileName (?))
URLs are just usually too long to fit in to a tab nicely.
Smaug, yes I checked in a slightly different version after talking with jag and bz.

As for your comment about just wanting the filename, what good is it if every
tab is labeled "index.html" ?  Yes, URLs are long but that's why I crop it in
the center if I use a URL for the label...
Usually index.html -files do have titles, but
some else haven't.
But it was just a suggestion.
Or at least the nsIURL.filePath is better. I don't want to see
tabs labeled something like "http://....html"

Comment 15

16 years ago
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Nominating for adt1.0.1.

ADT: this is a fairly highly visible bug.  Users are bound to encounter it
sometimes.  Various ways they can encounter it include visiting pages like stock
tickers which meta refresh, hitting the stop button while loading a page, and
clicking on javascript links (popup windows).  When the user does encounter it,
while it is not serious, it can confuse the user who is trying to find a
specific tab in his tab list.  The fix is low risk, with a pretty high user gain
Keywords: adt1.0.1
i agree w/Christopher, this would be a Good Thing Indeed for the branch.

i've verified practically all of the bugs in the blocker list. my test result
details can be seen at
Whiteboard: [adt2] → [adt2][vrfy'd bugs w/trunk builds]

Comment 18

16 years ago
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Drivers' approval. pls check this in asap, then replace "mozilla1.0.1+" with
Blocks: 143047
Keywords: adt1.0.1 → adt1.0.1+, approval, mozilla1.0.1
Whiteboard: [adt2][vrfy'd bugs w/trunk builds] → [adt2 RTM][vrfy'd bugs w/trunk builds]
Comment on attachment 92187 [details] [diff] [review]
Patch v.1.1

Removing trunk approval since this already landed on the trunk and now needs
branch approval.
Attachment #92187 - Flags: approval+
Comment on attachment 92187 [details] [diff] [review]
Patch v.1.1

Approved for branch checkin
Attachment #92187 - Flags: approval+


16 years ago
Keywords: mozilla1.0.1 → mozilla1.0.1+
Landed on the branch.
Last Resolved: 16 years ago
Keywords: mozilla1.0.1+ → fixed1.0.1
Resolution: --- → FIXED

Comment 22

16 years ago
So, do we need a contentDocumentTitle property?
(all this getter business is ugly :-)
vrfy'd fixed using 2002.08.19.xx-1.0 comm branch builds on linux rh7.2, mac 9.1
and 10.1.5, and win2k.
Keywords: fixed1.0.1 → verified1.0.1
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.