Closed Bug 273660 Opened 21 years ago Closed 15 years ago

Use "Blank", rather than "(Untitled)" for blank tabs

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

()

Status:
RESOLVED DUPLICATE of bug 552166

People

(Reporter: moz-spam-filtered.20.nickj, Assigned: dprinsloo)

References

Details

Attachments

(1 file, 6 obsolete files)

Patch version 2 screen-shot, showing build version numbers
56.13 KB, image/jpeg
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 The name "(Untitled)" for about:blank tabs is simply not user-friendly. The only thing it actually tells you is that the page has no title, whilst the parentheses in "(Untitled)" seem to serve no obvious purpose. The title "Blank" is shorter, clearer, and to-the-point. A 2-line patch that I use on my Firefox 1.0 installation to change this behaviour is as follows: From toolkit.jar, edit chrome\toolkit\content\global\bindings\tabbrowser.xml ~line 789: ========================================================== <method name="setTabTitle"> <parameter name="aTab"/> <body> <![CDATA[ var browser = this.getBrowserForTab(aTab); var crop = "end"; var titleViaGetter = browser.contentDocument.__proto__.__lookupGetter__('title').call(browser.contentDocument); var title; if (titleViaGetter) title = titleViaGetter else if (browser.currentURI.spec && browser.currentURI.spec != "about:blank") { title = browser.currentURI.spec; crop = "center"; } + else if (browser.currentURI.spec && browser.currentURI.spec == "about:blank") + title = "Blank"; else title = this.mStringBundle.getString("tabs.untitled"); aTab.label = title; aTab.setAttribute("crop", crop); ]]> </body> </method> ========================================================== Note that a better patch may be to update the title attribute in the C++ file that has a static string defining the about:blank page's HTML (I forget the exact name of that file, but it's something like NsAboutBlank.cpp). Also, the old "(Untitled)" name can very very briefly be seen with the above patch when opening a new tab, before it changes to "Blank". Reproducible: Always Steps to Reproduce:
couldn't find anything about it, confirming.
Severity: enhancement → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: For blank tabs use a tab label of "Blank", rather than "(Untitled)" → Use "Blank", rather than "(Untitled)" for blank tabs
Version: unspecified → Trunk
*** Bug 305107 has been marked as a duplicate of this bug. ***
(From bug 305107:) I suggest leaving the tab's title blank.
> I suggest leaving the tab's title blank. Fine by me - either "Blank", or a blank title ("") would be an improvement. Just please no parentheses, or the word "Untitled".
Patch coming after I update my tree.
Status: NEW → ASSIGNED
Attached patch strip title altogether (obsolete) — — Splinter Review
This strips the tab title altogether. I prefer this one.
Attachment #193121 - Flags: review?(mconnor)
Attached patch replace title with "Blank" (obsolete) — — Splinter Review
Second option of replacing title with "Blank," although I do not prefer this one. I'm not requesting review on this, but if mconnor wants to pick this instead (if any), then he knows what to do :)
Looks good to me! Thank you!
Leaving it with nothing...would look funny. Changing it from (Untitled) to Blank really doesn't help/change anything.
> Leaving it with nothing...would look funny. It honestly doesn't look that funny. I know it's probably a bit different from what you're used to, but it does make it very quick and easy to see which tabs are empty when you've got lots of them open (no need to read the labels, just scan for the tab without any writing). No label is what I've been using for nearly 3 months now (since tonglebeak's patch), and it's grown on me, so I'd slightly prefer it to "Blank", although either is better than the current situation. > Changing it from (Untitled) to Blank really doesn't help/change anything. For a technical perspective it changes nothing; but from a UI perspective it's like comparing darkness and light. Would you write: "Give someone a blank cheque" ? Or "give someone an untitled cheque" ? or "give someone an (untitled) cheque" ? Each one is progressively worse. "Blank" is short, simple, descriptive, and as a bonus it doesn't have the completely pointless parentheses.
Comment on attachment 193121 [details] [diff] [review] strip title altogether This looks broken, really. Discussed this at far too much length, and (Empty Tab) was the agreed-upon term (with parens!)
Attachment #193121 - Flags: review?(mconnor) → review-
So... WONTFIX? :)
Assignee: bugs → nobody
Status: ASSIGNED → NEW
Wontfix? Aaron Slunt said: "Patch coming after I update my tree." I added comments to the dup: ".. I'd also add another Icon to it! Maybe the same blank-document Icon but with a yellow glowing * at it. (See Open Dialog: "Create New Folder" for example)" Problem is: Any "Name" could be the actual title of a real page! But you cannot name a page "" (<<- nothing!). Not via html. But maybe somehow else.
Hi all.I want to try to fix this bug. I need to contribute minimally to an open-source for an assignment. But I would love to contribute to the Firefox project in more meaningful ways later. To that end this is also a baby step to familiarize myself with working with the source code. I suggest that I make the empty tab read "Blank" or "(Empty Tab)", in order of my personal preference. I might even make multiple patches so that the powers-that-be can decide later on which one is the best. I will also try the possibility of inserting certain common Unicode characters that might help a user to easily recognize blank tabs among dozens of tabs, only if it looks good. I also think that showing nothing looks really broken and looks ugly. Thus the main focus will be to improve the UI usability, but strictly stay with the default theme. I tried to address all the questions and comments raised with this bug to date.
Daniel: great! Have you seen https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch ? It describes the process of creating a patch and getting it committed to the source repository. Comment 11 describes the wanted (at that time at least) solution; you can get help going through the process on IRC (irc.mozilla.org/#developers).
This is a screenshot showing how it looks after changing the (Untitled) to (Empty Tab). I will now upload a patch for initial review after this post. I will describe briefly in the next post what I had to change and why it seems like I overkilled the patch. I appologize for the double post that will follow, but it seems only one attachment can be uploaded at a time.
Thank you for the help Nickolay. I have a few uncertainties about the entire patching process. As stated before I am completely new to contributing to any open-source project. My understanding of the source code is very limited, I had to make a few assumptions which I would like to receive feedback about. All the reasons above is why this patch should be seen as a preliminary patch. It is very similar to the first two patches except I added the changes to the tabbrowser.dtd files and not only tabbrowser.properties files. This extra change is where I especially would appreciate feedback. Please refer to the patch to see the paths of the files I mention in this post several times. I still not sure what role the .dtd file plays in terms of the label of a empty tab. I played around and after changing the dtd files there seems to be no effect on the tab label, while changing any other entity in the tabbrowser.dtd file is reflected by the build. The only code that uses the dtd entity that I could find is in the tabbrowser.xml file inside the <xul:tab> tag that has a label property that uses a reference to the .dtd untitled tab string. I also read that .dtd files are there to help with UI language translation. Thus the conclusion I made is that the properties file could be altered via the .dtd file to reflect language changes, either by browser or a plugin. If I am even slightly on track with this assumption then it means a patch that only patches the tabbrowser.properties file is incomplete. If the properties file and the .xml and .dtd files are used separately or at different times then the labels of new tabs could vary during runtime and some show up as (Untitled) while others show up as (Empty Tab), clearly a situation that must be avoided. I don't think it is necessary to run the automated tests and litmus tests with this patch, the users on IRC #developers channel also confirmed this. I think that about sums it up. Thank you for reading this post.
Attachment #393360 - Flags: review?(mconnor)
Hi again. Judging from your patch, you checked out the source code from CVS. Firefox is using a different source control system since after 3.0, so your patch is for Firefox 3.0.x. While it won't be that different in this particular case, we usually ask to submit patches against the latest version ("trunk"). See https://developer.mozilla.org/En/Developer_Guide/Source_Code/Mercurial for instructions to get it (you want the "mozilla-central" repository). As a bonus, there won't be the confusing files in xpfe/, which belong to SeaMonkey, not Firefox. As for the DTD issue, your analysis is right. From a quick look it appears that the entity is in fact not used (the initial label of the first tab is overriden via setTabTitle() anyway), but there are quite a few preferences that affect what's happening at startup, so since you just want to change the title, it's better to just change both strings. I think it's best if you attach a hg patch and I would probably ask a different reviewer from the list at http://www.mozilla.org/projects/firefox/review.html (or maybe just ask on IRC who is the most responsive reviewer for this code nowadays :)
Thank you once again Nickolay, I have learned allot. Especially about Mercurial and the Mozilla build system after many failed build attempts. I am still wondering why I used older source code and CVS, must have had a moment. I have used Mercurial to get the Mozilla-central repository and compiled the browser. I think I will still ask Mr M. Conner for a preliminary review, because he has reviewed the first patch and someone else suggested him also in the #developers IRC channel. I will also post an updated screen-shot to show for which version I created the patch.
Attachment #393360 - Attachment is obsolete: true
Attachment #393421 - Flags: review?(mconnor)
Attachment #393360 - Flags: review?(mconnor)
I apologize for this double post, but I feel it is necessary to prove I used an acceptable build.
Attachment #393349 - Attachment is obsolete: true
Attachment #193121 - Attachment is obsolete: true
Attachment #193122 - Attachment is obsolete: true
Attachment #193125 - Attachment is obsolete: true
You accidentally switched tabbrowser.properties to Windows-style line endings, which is why the patch looks like you're removing many lines then adding them back. This is frowned upon and should be fixed before committing the patch. Otherwise great, if you don't get a review in a week or so, try pinging mconnor on IRC or looking for a another reviewer.
Assignee: nobody → dprinsloo
When changing a string you need to revise its name as well, so localizers get notified about it.
(In reply to comment #21) > You accidentally switched tabbrowser.properties to Windows-style line endings, > which is why the patch looks like you're removing many lines then adding them > back. This is frowned upon and should be fixed before committing the patch. Thank you again Nickolay. I have downloaded a specific utility that has fixed this. I will also ensure that I don't make this mistake again. (In reply to comment #22) > When changing a string you need to revise its name as well, so localizers get > notified about it. Yes Vlado, you are right. It will become confusing as it is not a good idea to have more than one name to refer to a specific variable in code. The only problem I have now is that there are other references to untitled that does not refer to tabs but to pages and URL's e.g. URL has the untitled string from line 1138 of /widget/src/windows/nsDataObj.cpp wcscpy(fileGroupDescW->fgd[0].cFileName,NS_LITERAL_STRING("Untitled.URL").get()); But I will go ahead and assume that the concept of an empty tab is clear and is separate concept from pages, URL's, etc. I see tab as a container, which is "empty" initially rather than untitled. I will need some time to prepare a new patch that addresses the names and not only the string values. I will also determine if it might become necessary to run tests, due to changing variable names.
Attachment #393421 - Attachment is obsolete: true
Attachment #393421 - Flags: review?(mconnor)
Daniel: hey, just a reminder that there's no pending review request in this bug, you were going to attach a new patch...
bug 552166 changed (Untitled) to "New Tab", marking this one as a dupe of that. I don't suppose anyone cares about New Tab vs Blank...
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
"New Tab" is great - and thank you Nickolay for the heads up that this is now resolved!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: