Closed Bug 1366870 Opened 7 years ago Closed 7 years ago

Reduce new tab loading titles to the URL's hostname (without protocol and www.)

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Version:
55 Branch
Platform:
All
Unspecified
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 56
Tracking Flags:
Tracking Status
firefox55 --- fixed
firefox56 --- verified

People

(Reporter: caspy77, Assigned: cpeterson)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

Bug 1366870 - Part 1: Add test for about: pages' initial tab titles.
59 bytes, text/x-review-board-request
dao
: review+
jcristau
: approval-mozilla-beta+
Details
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.
59 bytes, text/x-review-board-request
dao
: review+
jcristau
: approval-mozilla-beta+
Details 
If it is now a requirement to display the URL in the tab title before the page title is received, let's strip out http:// (or https://) and "www.". 

These look ugly enough and don't add much.  If anything they push more of the domain off to the right and reduce the ability to recognize the URL. My windows are filled to the max width for tabs so I'm seeing a *lot* of https://www.
Sorry, I should have specified that this is reflecting the behavior I'm seeing on Nightly.
Or instead of showing the complete URL (e.g. "https://en.m.wikipedia.org/wiki/Main_Page"), maybe show something less technical and more user-friendly like:

- the URL without the URL scheme: "en.m.wikipedia.org/wiki/Main_Page"
- just the domain name: "en.m.wikipedia.org"
- or just the TLD+1: "wikipedia.org"

My preference is for showing just the TLD+1. The user thinks "I am opening a Wikipedia tab" and then sees a tab titled "wikipedia.org". With this approach, you avoid avoid tab titles with "www." prefixes (which are just as unhelpful as tab titles like "https://...") without special heuristics for deciding which subdomain names are meaningful for users or not.

In this Wikipedia example, the tab title would transition from "wikipedia.org" to "Wikipedia, the free encyclopedia". These strings share the same prefix, so the transition would be pretty subtle.
Blocks: 1359352
(In reply to Chris Peterson [:cpeterson] from comment #2)
> Or instead of showing the complete URL (e.g.
> "https://en.m.wikipedia.org/wiki/Main_Page"), maybe show something less
> technical and more user-friendly like:
> 
> - the URL without the URL scheme: "en.m.wikipedia.org/wiki/Main_Page"
> - just the domain name: "en.m.wikipedia.org"
> - or just the TLD+1: "wikipedia.org"
> 
> My preference is for showing just the TLD+1. The user thinks "I am opening a
> Wikipedia tab" and then sees a tab titled "wikipedia.org". With this
> approach, you avoid avoid tab titles with "www." prefixes (which are just as
> unhelpful as tab titles like "https://...") without special heuristics for
> deciding which subdomain names are meaningful for users or not.
> 
> In this Wikipedia example, the tab title would transition from
> "wikipedia.org" to "Wikipedia, the free encyclopedia". These strings share
> the same prefix, so the transition would be pretty subtle.

How would this work for sites that have different subdomains based on which user/company page you are visiting? Or what about the difference between wiki.mozilla.org and bugzilla.mozilla.org?

Stripping known conventions like www seems less harmful than blanket showing only TLD+1.
For comparison, here are the tab titles shown by other browsers when opening a new tab before the new page's <title> is known. To test, I opened new tabs using Ctrl+click from https://support.microsoft.com/en-us because it has links to other sites with different subdomain names, such as answers.microsoft.com, account.microsoft.com, and www.microsoft.com.

- Firefox <= 54: "Connecting..."
- Firefox 55: "http://answers.microsoft.com/en-us" (the full URL)
- Safari: "Untitled"
- Chrome: "Loading..."
- IE 11: "answers.microsoft.com" when opening "https://answers.microsoft.com", but just "microsoft.com" (without "www." prefix) when opening "https://www.microsoft.com".
- Edge: "Blank page"

So IE is the only browser the implements the "domain name minus 'www.' prefix" suggestion. Interesting that Edge shows "Blank page" instead of domain names like IE.
(In reply to Caspy7 from comment #0)
> If it is now a requirement to display the URL in the tab title before the
> page title is received

Is this a requirement? NI Panos about that...

Thanks for the thorough listing of what other browsers are doing Chris!
I agree that something like »Loading« would be more useful in these contexts.
Flags: needinfo?(past)
The URL is displayed for new tabs since bug 1364127, but I can't remember if we discussed this in Toronto. I think the rationale was to provide information to the user as soon as possible, but perhaps this runs counter to the goal of improving perceived performance?
Flags: needinfo?(past) → needinfo?(dao+bmo)
We used to show "New Tab" instead of "Loading..." after bug 1359352.
The rationale was that showing "New Tab" or no label at all would be unhelpful or look broken, and the URL is the next best thing we can show. We were working under the assumption that we do not want to show Loading/Connecting, since that's what we were asked to remove in the first place in bug 1359352.
Flags: needinfo?(dao+bmo)
(In reply to Dão Gottwald [::dao] from comment #8)
> The rationale was that showing "New Tab" or no label at all would be
> unhelpful or look broken, and the URL is the next best thing we can show. We
> were working under the assumption that we do not want to show
> Loading/Connecting, since that's what we were asked to remove in the first
> place in bug 1359352.

My understanding from bug 1359352 is that the previous undesirable experience was that users would see was:
<previous title> -> "New Tab" -> <new title>
And sometimes the temporary title may only be there very briefly. So altogether this is a noisy and jarring experience.

One of my main objections for the current behavior, as it relates to opening links new tabs, is that the temporary title could be displayed only very briefly. So if we're giving the user novel information to take in (a URL), then it may disappear quickly, this is a form of frustration (Should I have read that? What did I miss? Hey! I was reading that!). Along with (and you may think this silly) an extra reading assignment they didn't have before, that they have to process.

Alternatively, a static text placeholder mitigates this. After a few uses it becomes another icon that does not require effort to understand or add additional noise.

I understand the idea of giving the URL as it provides more information to the user, but I think in this case it works more against the user than for them so I think we should go with "Loading..." instead.
I attached patches for both the "domain name minus www prefix" and "Loading…" proposals. You can download test builds to compare them firsthand (by Ctrl+clicking links to open them in new tabs). I like the domain name titles, but the "Loading" titles are less noisy, as Caspy describes.

Firefox 54 uses "Connecting…". I also discovered that Chrome uses "Loading…" on Windows and "Untitled" on Mac (like Safari).

The Loading builds will be available here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d5aa2533e2382ca66f107339e58132f6359fb38e

The domain name builds will be available here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7bea599cab706ba49291b9dcf73e701f7d84a4b9
The Loading builds are available here:
https://archive.mozilla.org/pub/firefox/try-builds/cpeterson@mozilla.com-d5aa2533e2382ca66f107339e58132f6359fb38e/

The domain name builds are available here:
https://archive.mozilla.org/pub/firefox/try-builds/cpeterson@mozilla.com-7bea599cab706ba49291b9dcf73e701f7d84a4b9/

I find the domain name titles give the illusion that the browser has already connected to the server, while the Loading titles feel like the browser is still struggling to just open a new empty tab.
Let's go with whatever Philipp likes the most.
Flags: needinfo?(philipp)
Thanks for putting in the work to create both patches!

Looking at the builds, I agree that the domain name gives the impression of Firefox having already loaded part of the page, which is great! It will also degrade more gracefully when a page actually does take a long time to load and looks much less noisy than the previous »http://...« version.

So let's go with the domain name!
Flags: needinfo?(philipp)
Assignee: nobody → cpeterson
Component: Theme → Tabbed Browser
Oh, I meant to mention, when testing the domain name build, I tested on two sites that I commonly open multiple links from: Google news and reddit.  

I observed that for both sites each opened link showed news.google.com or out.reddit.com (respectively) until the title displayed. Likewise links opened from searches in google and yahoo show google.com and r.search.yahoo.com.
So <url> -> <title> immediately with no intermediate.

This could raise an issue or two.  These are redirect sites, not used infrequently online (sometimes for nefarious purposes), but if we update the URL in realtime it seems like we go back to the "noisy" reason this was changed in the first place.
I suppose, at least in the case of redirect sites, the argument for showing the URL to help inform the user goes away.

Not trying to dog-with-a-bone the topic, the URL doesn't come off horrible in general, but this is one of the first things I noticed when testing.
Comment on attachment 8872495 [details]
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.

https://reviewboard.mozilla.org/r/144016/#review148266

::: browser/base/content/tabbrowser.xml:1442
(Diff revision 2)
>        <method name="setTabTitleLoading">
>          <parameter name="aTab"/>
>          <body/>
>        </method>
>  
> +      <method name="setInitialTabTitleFromURI">

Shouldn't you just do this in setInitialTabLabel for the !aOptions.isContentTitle case?

::: browser/base/content/tabbrowser.xml:1456
(Diff revision 2)
> +            return;
> +          }
> +
> +          // Some tests pass in values that are not valid URLs, such as
> +          // "example.com" with no scheme. Just show whatever was passed in
> +          // until we know the page's actual title.

Perhaps we should use nsIURIFixup here?

::: browser/base/content/tabbrowser.xml:1466
(Diff revision 2)
> +          }
> +
> +          let title;
> +          if (url) {
> +            const hostname = url.hostname;
> +            title = hostname.startsWith("www.") ? hostname.slice(4) : hostname;

Also need to handle empty hosts in e.g. file URIs.

::: browser/components/sessionstore/test/browser_tab_label_during_restore.js:84
(Diff revision 2)
>    gBrowser.selectedTab = thirdTab;
>    await browserLoadedPromise;
>    ok(!thirdTab.hasAttribute("pending"), "third tab isn't pending anymore");
>    is(thirdTab.label, ABOUT_ROBOTS_TITLE, "third tab displays content title");
>    ok(document.title.startsWith(ABOUT_ROBOTS_TITLE), "title bar displays content title");
> -  checkLabelChangeCount(1);
> +  checkLabelChangeCount(2);

What are the expected label changes here? Might be a good idea to change observeLabelChanges such that it would require the caller to specify this.
Attachment #8872495 - Flags: review?(dao+bmo) → review-
Comment on attachment 8872494 [details]
Bug 1366870 - Part 1: Add test for about: pages' initial tab titles.

https://reviewboard.mozilla.org/r/144014/#review148272

::: browser/components/sessionstore/test/browser_tab_label_during_restore.js:86
(Diff revision 3)
> +  ok(!thirdTab.hasAttribute("pending"), "third tab isn't pending anymore");
> +  is(thirdTab.label, ABOUT_ROBOTS_TITLE, "third tab displays content title");
> +  ok(document.title.startsWith(ABOUT_ROBOTS_TITLE), "title bar displays content title");
> +  checkLabelChangeCount(1);
> +
>    info("restoring the modified browser state");

I'd prefer doing this with the second tab selected rather than the third one since the latter is a special case.
(In reply to Caspy7 from comment #20)
> I observed that for both sites each opened link showed news.google.com or
> out.reddit.com (respectively) until the title displayed. Likewise links
> opened from searches in google and yahoo show google.com and
> r.search.yahoo.com.
> So <url> -> <title> immediately with no intermediate.

@ Philipp, is this redirect behavior worse than showing a generic "Loading..."?

The user hovers over a link on the news.google.com page that ostensibly points to "https://www.nytimes.com/..." (according to the browser status bar) but opening the link in new tab shows the temporary tab title "news.google.com" before changing to "The New York Times".

This might surprise a user who is paying close attention, but the tab does show what is really happening. The temporary "news.google.com" title might not be that confusing, however, since the user is browsing *from* that same URL. In this Google News case, the tab title is not an unrelated third-party domain name, but it could be when clicking short URLs on social media or ads on third-party ad servers.
Flags: needinfo?(philipp)
(In reply to Dão Gottwald [::dao] from comment #21)
> > +      <method name="setInitialTabTitleFromURI">
> 
> Shouldn't you just do this in setInitialTabLabel for the
> !aOptions.isContentTitle case?

AFAICT, that would cover the call to setInitialTabTitle from SessionStore.jsm [1] (during session restore), but not from tabbrowser.xml (when opening a new tab). I could check for `(!aOptions.isContentTitle || aOptions.beforeTabOpen), but that was starting to feel more fragile than just adding a new setInitialTabTitleFromURI function. The SessionStore.jsm caller code [1] would still need to know whether to call setInitialTabTitle with activePageData.title or activePageData.url, so the extra magic instead setInitialTabTitle doesn't make the caller code any simpler.

[1] https://searchfox.org/mozilla-central/source/browser/components/sessionstore/SessionStore.jsm#2649
[2] https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser.xml#2378


> > +          // Some tests pass in values that are not valid URLs, such as
> > +          // "example.com" with no scheme. Just show whatever was passed in
> > +          // until we know the page's actual title.
> 
> Perhaps we should use nsIURIFixup here?

Thanks. I didn't know about nsIURIFixup. I'll look into it.


> ::: browser/base/content/tabbrowser.xml:1466
> (Diff revision 2)
> > +          }
> > +
> > +          let title;
> > +          if (url) {
> > +            const hostname = url.hostname;
> > +            title = hostname.startsWith("www.") ? hostname.slice(4) : hostname;
> 
> Also need to handle empty hosts in e.g. file URIs.

Thanks. I'll fix that. Firefox 53 shows the full file:// URI in the tab title, so I will do that.
(In reply to Dão Gottwald [::dao] from comment #22)
> browser/components/sessionstore/test/browser_tab_label_during_restore.js:86
> (Diff revision 3)
> > +  ok(!thirdTab.hasAttribute("pending"), "third tab isn't pending anymore");
> > +  is(thirdTab.label, ABOUT_ROBOTS_TITLE, "third tab displays content title");
> > +  ok(document.title.startsWith(ABOUT_ROBOTS_TITLE), "title bar displays content title");
> > +  checkLabelChangeCount(1);
> > +
> >    info("restoring the modified browser state");
> 
> I'd prefer doing this with the second tab selected rather than the third one
> since the latter is a special case.

Thanks. I'll fix that.
(In reply to Chris Peterson [:cpeterson] from comment #24)
> (In reply to Dão Gottwald [::dao] from comment #21)
> > > +      <method name="setInitialTabTitleFromURI">
> > 
> > Shouldn't you just do this in setInitialTabLabel for the
> > !aOptions.isContentTitle case?
> 
> AFAICT, that would cover the call to setInitialTabTitle from
> SessionStore.jsm [1] (during session restore), but not from tabbrowser.xml
> (when opening a new tab). I could check for `(!aOptions.isContentTitle ||
> aOptions.beforeTabOpen), but that was starting to feel more fragile than
> just adding a new setInitialTabTitleFromURI function. The SessionStore.jsm
> caller code [1] would still need to know whether to call setInitialTabTitle
> with activePageData.title or activePageData.url, so the extra magic instead
> setInitialTabTitle doesn't make the caller code any simpler.

Except for "New Tab" (which should be irrelevant for setInitialTabTitle), there's only two types of titles -- content titles and URIs. I.e. the absence of isContentTitle can be treated as "is URI", and the tabbrowser.xml call from opening a new tab should work as is.
Here is a green Try run for patch 1, the changes to the browser_tab_label_during_restore.js test. This test change documents the current behavior of about: pages's initial tab titles. The fix for bug 1364127 caused about: pages' initial tab titles to show their about: URIs until their actual page titles are known, e.g. "about:addons" -> "Add-ons Manager". This is bug 1371896. Previously, about: pages' initial tab titles were blank until the page title was known. This test change might not belong in this bug. I originally planned to fix this bug and the "about:addons" initial tab titles in one patch, but I decided to separate the changes so I could land this fix sooner.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=20902e4b9e3cc1ea72c105399026c0824870685f&selectedJob=106037705

Here is a green Try run for patches 1 and 2:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6f3ebd75dc4f45274c5e455db95c76af87b6f834&selectedJob=106038498
Comment on attachment 8872494 [details]
Bug 1366870 - Part 1: Add test for about: pages' initial tab titles.

https://reviewboard.mozilla.org/r/144014/#review152142
Attachment #8872494 - Flags: review?(dao+bmo) → review+
Comment on attachment 8872495 [details]
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.

https://reviewboard.mozilla.org/r/144016/#review152144

Thanks!
Attachment #8872495 - Flags: review?(dao+bmo) → review+
Comment on attachment 8872495 [details]
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.

https://reviewboard.mozilla.org/r/144016/#review152146

::: browser/base/content/tabbrowser.xml:1473
(Diff revision 3)
> +            // "example.com" with no scheme. Just show whatever was passed in
> +            // until we know the page's actual title.
> +            let hostname;
> +            try {
> +              const fixedURI = URIFixup.createFixupURI(uri, URIFixup.FIXUP_FLAG_NONE);
> +              hostname = fixedURI.host;

Wait, I think this still doesn't handle file URIs...
Comment on attachment 8872495 [details]
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.

https://reviewboard.mozilla.org/r/144016/#review152146

> Wait, I think this still doesn't handle file URIs...

It kinda handles file: URIs, but can be improved. fixedURI.host returns "" which causes the file: URI's initial tab title to be blank before eventually switching to the file: URI title. So this patch doesn't display a *wrong* initial tab title, but it does cause an unnecessary delay before the file: URI title.

I can fix this by return the original URI when the URI has no hostname. The initial tab title is then the file: URI and there is no blank delay.
Comment on attachment 8872495 [details]
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.

https://reviewboard.mozilla.org/r/144016/#review152162

::: browser/base/content/tabbrowser.xml:1464
(Diff revision 3)
> +          }
> +
> +          function getHostnameWithoutWWW(uri, URIFixup) {
> +            // about: pages don't have hostnames, so we can bail early here.
> +            if (uri.startsWith("about:")) {
> +              return uri;

btw, returning null here for about: URIs appears to fix bug 1364127, but then causes browser_tab_label_during_restore.js to fail in non-e10s mode with extra tab title transitions from "" -> "New Tab" -> ABOUT_ROBOTS_TITLE. In e10s mode, some of the tab title transitions appear to be dropped. I did not understand why, so I filed bug 1364127 instead of trying to fix two existing problems in this one patch.
Dão, I'm needinfo'ing you because I changed patch 2 to handle the file: URI case, but MozReview won't allow me to request a new review for the new patch because it has your r+ from the earlier version.

Patch 2 now return the original URI if the input has not hostname, either if URIFixup.createFixupURI throws an error or fixedURI.host is an empty string "" (which is falsy).
Flags: needinfo?(philipp) → needinfo?(dao+bmo)
Sounds good, although I think the mozreview commits are messed up.
Flags: needinfo?(dao+bmo)
Pushed by cpeterson@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4111a13b009f
Part 1: Add test for about: pages' initial tab titles. r=dao
https://hg.mozilla.org/integration/mozilla-inbound/rev/e09b9ac57d9f
Part 2: Set initial tab title to URL's hostname until we know the actual page title. r=dao
https://hg.mozilla.org/mozilla-central/rev/4111a13b009f
https://hg.mozilla.org/mozilla-central/rev/e09b9ac57d9f
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 56
I have reproduced this bug with Nightly 55.0a1 (2017-05-22)  on Ubuntu 16.04, 64 bit!

The Bug's fix is now verified on Latest Nightly 56.0a1.

Build ID 	20170613100218
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
QA Whiteboard: [bugday-20170614]
Status: RESOLVED → VERIFIED
status-firefox56: fixed → verified
+ fixing summary
Summary: Strip off http:// from new tab loading titles → Strip off "https://" & "https://www" & "http://" & "http://www" from new tab loading titles and show only URL's hostname
We should uplift this to complete related changes made in 55 and to enable future uplifts based on this (e.g. bug 1367630). cpeterson, would you mind filling out the uplift request?
Flags: needinfo?(cpeterson)
Summary: Strip off "https://" & "https://www" & "http://" & "http://www" from new tab loading titles and show only URL's hostname → Reduce new tab loading titles to the URL's hostname (without protocol and www.)
Comment on attachment 8872494 [details]
Bug 1366870 - Part 1: Add test for about: pages' initial tab titles.

Approval Request Comment
[Feature/Bug causing the regression]: bug 1359352
[User impact if declined]: Users will see ugly URLs as initial tab titles.
[Is this code covered by automated tests?]: Yes. This patch updates the automated test.
[Has the fix been verified in Nightly?]: Yes. See Md. Majedul Islam's verification in comment 14.
[Needs manual test from QE? If yes, steps to reproduce]: No. We have an automated test.
[List of other uplifts needed for the feature/fix]:
[Is the change risky?]: No.
[Why is the change risky/not risky?]: Not risky because it just changes the tab titles and includes a test.
[String changes made/needed]: No localized string changes.
Flags: needinfo?(cpeterson)
Attachment #8872494 - Flags: approval-mozilla-beta?
Comment on attachment 8872495 [details]
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.

Approval Request Comment
[Feature/Bug causing the regression]: bug 1359352
[User impact if declined]: Users will see ugly URLs as initial tab titles.
[Is this code covered by automated tests?]: Yes. This patch fixes the bug and updates the automated test.
[Has the fix been verified in Nightly?]: Yes. See Md. Majedul Islam's verification in comment 14.
[Needs manual test from QE? If yes, steps to reproduce]: No. We have an automated test.
[List of other uplifts needed for the feature/fix]:
[Is the change risky?]: No.
[Why is the change risky/not risky?]: Not risky because it just changes the tab titles and includes a test.
[String changes made/needed]: No localized string changes.
Attachment #8872495 - Flags: approval-mozilla-beta?
Comment on attachment 8872494 [details]
Bug 1366870 - Part 1: Add test for about: pages' initial tab titles.

new test, beta55+
Attachment #8872494 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8872495 [details]
Bug 1366870 - Part 2: Set initial tab title to URL's hostname until we know the actual page title.

tweak initial title after bug 1359352, beta55+
Attachment #8872495 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Chris Peterson [:cpeterson] from comment #45)
> [Is this code covered by automated tests?]: Yes. This patch fixes the bug
> and updates the automated test.
> [Has the fix been verified in Nightly?]: Yes. See Md. Majedul Islam's
> verification in comment 14.
> [Needs manual test from QE? If yes, steps to reproduce]: No. We have an
> automated test.

Setting qe-verify- based on Chris' assessment on manual testing needs and the fact that this fix has automated coverage.
Flags: qe-verify-
Blocks: 1386538
Blocks: 1394188
I realized we're momentarily swapping out the page title for the URL on simple reloads and filed bug 1394188.
Blocks: 1515003
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: