Steps To Reproduce: 1. Set "New Tab" to "Blank Page" on about:preferences#home 2. Open "New Tab" 3. Select tab other than the "New Tab" 4. Exit browser and Restart browser 5. Alt > History > "Restore Previous Session" Actual Results: The "New Tab" tab label is empty Expected Results: "New Tab" tab label should be "New Tab"

Kate, can you please take a look at this?

Yep, I can reproduce this. Weirdly, the title shows up after focusing the window. Ed, you think this has something to do with the way this is implemented in AboutRedirector?

I've reproduced this behavior in Firefox 59 so doesn't look like a regression. I'm not sure about:blank has a title because the title it gets is set from here [0] which is just a fallback. The fact that is blank at restore might just be a consequence of "there is nothing to restore" and when you click the page it triggers the `setTabTitle` code. [0] https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/browser/base/content/tabbrowser.js#1310-1311 [1] https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/browser/locales/en-US/chrome/browser/tabbrowser.properties#5 <-- string definition

As per comment 3, about:blank is being restored and there's no title. Perhaps session restore could specially set a title. Otherwise probably wontfix?

There's a isBlankPageURL check to set "New Tab" tab titles https://searchfox.org/mozilla-central/rev/97d488a17a848ce3bebbfc83dc916cf20b88451c/browser/base/content/tabbrowser.js#2204-2205

Looks like restoring about:blank's "New Tab" title did regress sometime between 50 and 57

I'm a bit sad this got triaged as a P3, because we've caused a state that looks like something went horribly wrong.

I've narrowed this down as a regression from bug 1383599, using mozregression: 14:00.43 INFO: Narrowed inbound regression window from [9322f0ce, c68daf87] (3 builds) to [9322f0ce, 90ad5724] (2 builds) (~1 steps left) 14:00.43 INFO: No more inbound revisions, bisection finished. 14:00.43 INFO: Last good revision: 9322f0ce835f554a0108f59dba244f32ebd8d492 14:00.43 INFO: First bad revision: 90ad57245468c398be0be3fcdb2cdec1b9333232 14:00.43 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9322f0ce835f554a0108f59dba244f32ebd8d492&tochange=90ad57245468c398be0be3fcdb2cdec1b9333232

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40e24f40b4c4556944c762d4764eace261297f5&tochange=819a666afddc804b6099ee1b3cff3a0fdf35ec15 Looks like bug 1344857 changed the behavior for about:blank to explicitly record "about:blank" as the title whereas before, it would lack a title and default to "New Tab". https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1b065ffd8a535a0ad4c39a912af18e948e6a42c1&tochange=0985725c848ec0cfc6f2f3c3a5aa3d71321e7620 Then looks like bug 1367630 is the change that actually resulted in the restoring tab title to end up empty instead of showing "about:blank"

Looks like bug 1460423 is a dupe in Tabbed Browser. The bugs mentioned in comment 11 fall under Session Restore and Tabbed Browser. Unclear where the fix should land.. Either special case the session restore behavior to not save the title for about:blank or special case tabbed browser to use the empty tab title for about:blank?

Ed, thanks for jumping on this! Nice investigation skillz :) (In reply to Ed Lee :Mardak (PTO Sep 15 - Oct 7) from comment #12) > Looks like bug 1460423 is a dupe in Tabbed Browser. The bugs mentioned in > comment 11 fall under Session Restore and Tabbed Browser. Unclear where the > fix should land.. Either special case the session restore behavior to not > save the title for about:blank or special case tabbed browser to use the > empty tab title for about:blank? I think that's a good question for Dão to think about - this is indeed very closely related to bug 1367630. My gut tells me that adding a special case behavior for about:blank pages would fit best in tabbrowser... what do you think?

Third possibility: We don't restore blank tabs at all. If they don't contain state a user cares about, why bother?

(In reply to Mike Hoye [:mhoye] from comment #15) > Third possibility: We don't restore blank tabs at all. If they don't contain > state a user cares about, why bother? There are varying opinions and workflows that beg to differ - which we've been through before. So we used to not restore blank tabs - exactly in the same vein as your suggestion, but after various 'omg my tabs are missing' complaints we decided to just put that control back into the users' hands.

(In reply to Mike Hoye [:mhoye] from comment #15) > Third possibility: We don't restore blank tabs at all. If they don't contain state a user cares about, why bother? Blank tabs are useful. I am using them as separators (single blank tabs, or 2-3 blank consecutive tabs), between tabs with content. That way, I can divide all tabs in window into sections depending on the topic. In addition, I keeping tabs in different windows. Windows will serve as 1st level of subfolders, and sections of tabs in windows (separated by blank tabs) as 2nd/3rd level of subfolders. (That is the reason why Bug 1235231 is so annoying to me, since the order of windows is constantly changing after following restarts). [I had never used Tab Groups or other futures/addons. I prefer simple ways to organize tabs which are more resistant to software engineer's decisions about adding/removing futures. We can see what happened with Tab Groups for example. This also the reason why I am not planning to use Containers.]

(In reply to Robert Ab from comment #17) > Blank tabs are useful. I am using them as separators (single blank tabs, or > 2-3 blank consecutive tabs), between tabs with content. That way, I can > divide all tabs in window into sections depending on the topic. Robert, you can make a blank tab by opening this URL: data:text/html,<script>document.title="\u00a0"</script>

Or, slightly shorter, data:text/html,<title>&nbsp;</title>

(In reply to Mike de Boer [:mikedeboer] from comment #14) > Ed, thanks for jumping on this! Nice investigation skillz :) > > (In reply to Ed Lee :Mardak (PTO Sep 15 - Oct 7) from comment #12) > > Looks like bug 1460423 is a dupe in Tabbed Browser. The bugs mentioned in > > comment 11 fall under Session Restore and Tabbed Browser. Unclear where the > > fix should land.. Either special case the session restore behavior to not > > save the title for about:blank or special case tabbed browser to use the > > empty tab title for about:blank? > > I think that's a good question for Dão to think about - this is indeed very > closely related to bug 1367630. My gut tells me that adding a special case > behavior for about:blank pages would fit best in tabbrowser... what do you > think? SessionStore controls this: https://searchfox.org/mozilla-central/rev/c9272ef398954288525e37196eada1e5a93d93bf/browser/components/sessionstore/SessionStore.jsm#3495 https://searchfox.org/mozilla-central/rev/c9272ef398954288525e37196eada1e5a93d93bf/browser/components/sessionstore/SessionStore.jsm#2770-2771

In other words: the fix should land in Session Restore, Ed.

What's the desired behavior? Removing the about:blank check that dao referenced: } else if (activePageData.url != "about:blank") { That results in the title restoring as "about:blank" instead of empty. I believe that's because the page's title is empty string so it then defaults to the url.

Oh ha, I should just read the code more closely ;) The next line is just setting the initial title to be the url, which is about:blank. Are we wanting the restored title to be about:blank instead of empty or "New Tab" instead of empty?

Previous behavior was "New Tab", and that's currently what people are expecting.

(In reply to Mike Hoye [:mhoye] from comment #25) > Previous behavior was "New Tab", and that's currently what people are > expecting. This, indeed. :)

Pushed by elee@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b2156ede19a5 "New Tab" tab label is empty after restore previous session if restoring about:blank or new tabs set to "Blank Page" r=mikedeboer

I reproduced this issue on Windows 10 x64 with Fx 64.0a1 (20180905123750). The issue is no longer reproducible on Fx 64.0b4 (20181025233934) with Windows 10 x64, macOS 10.13 and Ubuntu 18.06 x64.