1676492 - Show the bookmarks toolbar for new tab / homepage set to blank page (about:blank)

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect, P3)

Description

[B.J. Herbison]

Steps to reproduce:

1. Set the New Tab preference to Blank Page.
2. Set the toolbar customization Bookmarks Toolbar option to Only on New Tab.
3. Open a new tab.
4. Set the "Homepage and new windows" preference to a custom URL.
5. Open a new window.
6. Set the "Homepage and new windows" preference to Firefox Home.
7. Open a new window.

Expected result:
3) The Bookmarks Toolbar appears on the new tab.
5) The Bookmarks Toolbar appears on the new tab.
7) The Bookmarks Toolbar appears on the new tab.

Actual result:
3) The Bookmarks Toolbar doesn't appear on the new tab.
5) The Bookmarks Toolbar doesn't appear on the new tab in the new window.
7) The Bookmarks Toolbar appears on the new tab in the new window.

Is a new window page a new tab page? I expect a typical user would think it was a new tab, and I consider the tab created when a window is open to be a new tab-- it certainly isn't a browser tab that existed before.

The option is called "Only on New Tab" but what it apparently should be called (at the current time) is "only on the Firefox Home (Default) page".

This is a regression from Bug 1674199 for the "Blank Page" configuration setting. I'm not sure about the Custom URLs... option.

Comment 1

[:Gijs (he/him)]

(In reply to B.J. Herbison from comment #0)

Thanks for keeping us honest here. This is all still somewhat in-progress.

Is a new window page a new tab page? I expect a typical user would think it was a new tab, and I consider the tab created when a window is open to be a new tab-- it certainly isn't a browser tab that existed before.

Arguably, clicking the "home" button also doesn't open a new tab but it does show the bookmarks toolbar, if you have "home" set to the default of the Firefox Home page.

I don't think of the thing in a new window as a "new tab" - it's a "new window". It's governed by a different preference.

Would it be clearer if it was all just one preference, and we treated new windows and tabs interchangeably in terms of which page they opened? Absolutely. Would that probably upset some other subset of users who are attached to the difference? Definitely. Is it a bunch of work to do, unifying those prefs, and would it imply changes to extension APIs / the effects those APIs have? Yep, that too. So we're not solving that gordian knot right now - but we also can't put everything else on hold until we do.

In the meantime, the meaning and the behaviour of the pref is completely obvious when using the default settings, and it's reasonable to talk about this page as "the new tab page", or "New Tab" for short. This is what shows up as the tab label when opening the page, so we're being consistent about terminology. We could make the option "Only show it when showing that page that shows up when you open a new tab", which would be more technically correct but obviously also... very unwieldy. We're not going to do that.

I don't know of a better, brief way of describing that page that isn't about internal codenames ("about:newtab", "User Journey", "Activity Stream", whatever), and definitely less understandable for users. So I think the labeling is staying how it is.

6. Set the "Homepage and new windows" preference to Firefox Home.
7. Open a new window.

Actual result:
7) The Bookmarks Toolbar appears on the new tab in the new window.

Because we disagree on what "new tab" means here, I actually am not 100% sure what you mean. Do you mean the initial tab shown in the new window shows the toolbar? Or doesn't it, but it's shown once you open another, new tab in that window? Or something else? (Needinfo for this.)

The option is called "Only on New Tab" but what it apparently should be called (at the current time) is "only on the Firefox Home (Default) page".

We're still reviewing the "blank page" support, but it has a number of serious technical issues (many of which you discovered, thank you!) because "about:blank" isn't always "really" a new blank tab, or the homepage (if that's set to about:blank), and distinguishing the two cases is not trivial. We'd like to support the blank page setting, but it wasn't possible for our initial attempt, because there were too many unforeseen edgecases.

Custom homepage support is a bit of a toss-up. If you set your homepage to mozilla.org or bbc.co.uk/news, should we always show the toolbar when you open those pages ? For now, we've decided the answer is "no", and therefore we don't show the bookmarks toolbar with that setting enabled.

FWIW, the subset of people who will go and configure these pages and switch to about:blank is going to be very minimal (and probably has a large overlap with people who turn the bookmarks toolbar always on or always off, anyway). Changing it then to be "Only on blank pages or the Firefox Home page" or whatever would be even more verbose...
I think behaviour for custom homepages is expected the way it is right now. We may change our mind if it turns out our notions of why/how/what pages people pick for that, and what their expectation is around whether they show the bookmarks toolbar, are all wrong.

Meanwhile, this feature is disabled by default in 84 once it leaves "early beta" stage. We'll run an experiment on release with the whole set of bookmarking-related changes while continuing to gather nightly feedback.

By comparison, Edge uses very similar phrasing with the same behaviour (doesn't show it for custom homepages, does show it for the default new window page, which is the same as the default new tab page). Chrome just calls it "Show Bookmarks bar", which makes even less sense, especially on the new tab page (where the context menu just gains and loses a checkmark without doing anything, because in Chrome there's no way to turn the bar off completely, so you're just toggling between having it always or only for new tabs/windows).

Comment 2

[B.J. Herbison]

Yes, for step 7 I was referring to the only tab created in a new window at the point a new window is created through File/New Window or control-N.

The custom URL homepage issue is interesting. If the custom URL is for a navigation page (such as a page of custom links) I could see the user wanting/benefiting from the bookmarks toolbar. If the custom URL is bbc.co.uk/news, a page to go to read for information, I could see the user not wanting the bookmarks toolbar. But the current preference would let the user select which is used.

Is there any telemetry available for which New Windows and Tabs options are used by how many people? That would be useful to have, and also add telemetry to see which of the new Boolmarks Toolbar options are selected by those users offer the new option (for each setting of New Windows and Tabs).

I don't know of a better, brief way of describing that page that isn't about internal codenames ("about:newtab", "User Journey", "Activity Stream", whatever), and definitely less understandable for users. So I think the labeling is staying how it is.

Actually, about:newtab is not an internal codename for the default Firefox new tab page (or at least shouldn't be). When the new tab page is set to Blank Page in preferences then about:newtab goes to a blank page and not the default Firefox new tab page.

Looking at preferences, under the "New Windows and Tabs" section is a "Firefox Home Content" section. So a better term for the default page is "Firefox Home".

One possible way out of this mess: When "Blank Page" is selected (either for windows or tabs) provide the user with Firefox Home, but displayed as though all of the check boxes were unchecked. The page wouldn't be totally blank, it would have the gear. (That would annoy me a little, but I wouldn't file a bug.) The drawback is that the checkboxes under Firefox Home Content would only apply some times (when Firefox Home is selected, not when Blank Page is selected). A more complicate change would be to have separate checkbox columns under Firefox Home Content for "homepage and new windows" and for "new tabs".

I'm not sure I like the suggestion in the previous paragraph, but I'll leave it in case it gives you useful ideas for an approach.

Other than those people who use a custom URL for a new window, how many people have the "homepage and new windows" and "new tabs" options set differently?

Comment 3

[:Gijs (he/him)]

Treating this like a regression doesn't really make sense.

Comment 7

[mi2rivtj]

What if Firefox Home but without any element on the screen (web search, top sites, highlights, snippets and the settings button) replaced the blank new tab page?

Comment 8

[mi2rivtj]

Sorry, I wrote the phrase in a wrong way, this is the correct one:
What if Firefox Home, without any element on the screen (web search, top sites, highlights, snippets and the settings button), replaced the blank new tab page?

Comment 20

[Earl Fogel]

I have a suggestion. Could we have another view option for the bookmarks toolbar? I.e.:

• Always Show
• Only Show on New Tab

Show on New Tabs and Windows

• Never Show

Comment 21

[John Wong]

I was to report this bug after not seeing the "bookmarks toolbar" on my new tab which is set to open a "blank page" in preferences.

However, when the new tab ist set to open the "Firefox (Home)" the bookmarks toolbar does show on new tabs.

Comment 22

[Jakub]

(In reply to :Gijs (he/him) from comment #1)

FWIW, the subset of people who will go and configure these pages and switch to about:blank is going to be very minimal (and probably has a large overlap with people who turn the bookmarks toolbar always on or always off, anyway).

From my perspective, the "Blank Page" setting is directed towards minimalists. And for such people, I think that the choice of option for toolbar is either "Only Show on New Tab" or "Never Show".

However, because there's an option to hide both Shortcuts and Recent Activity from default Firefox Home, I'm not sure if Blank Page (as an option for a new tab) is useful. Might consider removing it, which would fix this bug and other problems that were mentioned.

Comment 23

[bobbuun]

Removing "blank" is not a reasonable fix. The reason people use blank is when they want a new tab to be absolutely nothing. Hiding things from the home page doesn't make it a fully blank page.

Comment 24

[momchil.nikolov]

Can`t we have the best of both worlds? Blank page + only show on new tab working?
It is clear that FF does not consider a blank page "new tab", only if it is FF home page. So probably this is what needs to be modified somewhere in the code. I am not sure how complicated is that exactly...

Comment 25

[:Gijs (he/him)]

(In reply to momchil.nikolov from comment #24)

Can`t we have the best of both worlds? Blank page + only show on new tab working?
It is clear that FF does not consider a blank page "new tab", only if it is FF home page. So probably this is what needs to be modified somewhere in the code. I am not sure how complicated is that exactly...

I explained a bit in comment 1:

(In reply to :Gijs (he/him) from comment #1)

We're still reviewing the "blank page" support, but it has a number of serious technical issues (many of which you discovered, thank you!) because "about:blank" isn't always "really" a new blank tab, or the homepage (if that's set to about:blank), and distinguishing the two cases is not trivial. We'd like to support the blank page setting, but it wasn't possible for our initial attempt, because there were too many unforeseen edgecases.

Webpages can also open about:blank, and distinguishing the cases opened by the web and the ones opened by clicking the new tab button isn't straightforward at the point where we decide to toggle the bookmarks bar - we know what URL is being loaded, but not why.

We'd be happy for a patch here, but unfortunately it isn't trivial (see also e.g. the list of dependencies on bug 1674199).

Comment 26

[Jakub]

How about adding a setting that would make a Firefox Home page completely blank?
It would give the same result for the users and would circumvent the main problem of distinguishing the cases whether the blank page was opened by clicking the new tab button. Because, instead of opening "about:blank" url we would open a blank Firefox Home page.

Comment 27

[Jon Bauman [:jbauman:]]

Wow, that's a great point, Jakub! I work at Mozilla and even I never realized I could remove basically everything from the "new tab" view and get the behavior I wanted. I think we have all the pieces we need, if the affordances for customizing this behavior were more apparent, that might make provide more value to people who want this.

Comment 28

[:Gijs (he/him)]

(In reply to Jakub from comment #26)

How about adding a setting that would make a Firefox Home page completely blank?
It would give the same result for the users and would circumvent the main problem of distinguishing the cases whether the blank page was opened by clicking the new tab button. Because, instead of opening "about:blank" url we would open a blank Firefox Home page.

I think a number of people who pick "blank page" do so for performance reasons, and loading a page with a bunch of stuff in that then has to check a setting to not show anything is a lot more expensive than just about:blank. It also feels wrong to rewrite the entire implementation of "blank page" for these settings (which already exists) to use some other pref (and migrate users across). We also won't be able to remove the other settings entirely because they are used for custom URLs for homepages, and extension settings for the new tab page.

Comment 29

[Jakub]

(In reply to :Gijs (he/him) from comment #28)

It also feels wrong to rewrite the entire implementation of "blank page" for these settings (which already exists) to use some other pref (and migrate users across). We also won't be able to remove the other settings entirely because they are used for custom URLs for homepages, and extension settings for the new tab page.

I agree with you. User preferences shouldn't be changed based on implementation.

What do you think about creating something like about:blanknewtab? This way we could differentiate it from about:blank. This would also address performance issue.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 14 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 31

[simactest]

I can confirm this is still an issue in version 99. How does Firefox go about prioritizing issues? This issue has been open for 2 years and seems to have numerous duplicates.

Here's an overview of what I encountered:

There are 3 settings for showing the bookmarks toolbar. One of them being Only show on new tab. This setting works if you have the setting Homepage (Default) but does not work if you have Blank page selected.

Reproduce:

1. Set the bookmarks toolbar setting to Only show on new tab
2. Go into Settings>Home>New tabs (Blank Page)
   the bookmark toolbar does not show when opening a new tab.
3. go into settings>Home> New tabs (Homepage default)
   the bookmark toolbar shows on new tabs.

the bookmarks toolbar should show in both cases.

Comment 34

[Neil Deakin]

Attachment: Bug 1676492, create a special blank tab page that will show the bookmarks toolbar when 'Only Show on New Tab' is used' even when the new tab page is disabled, r=mardak

Comment 35

[Neil Deakin]

Attachment: Bug 1676492, show the bookmarks toolbar when a new window is opened when the preference is set to show a blank page, r=mardak

Depends on D154319

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bc76e6966ec9
create a special blank tab page that will show the bookmarks toolbar when 'Only Show on New Tab' is used' even when the new tab page is disabled, r=Gijs,Mardak
https://hg.mozilla.org/integration/autoland/rev/09fd88048f35
show the  bookmarks toolbar when a new window is opened when the preference is set to show a blank page, r=Mardak,preferences-reviewers

Comment 37

[Atila Butkovits]

Backed out for causing failures at test_navigation.py.

Backout link: https://hg.mozilla.org/integration/autoland/rev/71546f33a646b65f245e6efacc96330b4fdb247d

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=B8vmAG66QauPhv0kAmxK6g.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=09fd88048f358e7fe7188c48902f2e71f4250944

Failure log:
Marionette: https://treeherder.mozilla.org/logviewer?job_id=388934153&repo=autoland&lineNumber=28534
Webrender: https://treeherder.mozilla.org/logviewer?job_id=388934229&repo=autoland&lineNumber=142414

Comment 38

[Neil Deakin]

Investigating this failure led to an issue: when one opens a new tab, it opens the new blank page and it is added to the tab's history, so going to a new page will allow going back to the blank page -- normally a blank page cannot be returned to.

Comment 40

[Neil Deakin]

Attachment: Bug 1676492, when new tab page is configured to show a blank page, it should not be added to session history, r=gijs

Depends on D155003

Comment 41

[Neil Deakin]

Attachment: Bug 1676492, adjust tests to account for about:newtab being opened instead of a blank page, r=whimboo

Depends on D156303

Comment 42

[:Gijs (he/him)]

AIUI we can't land the changes here until either the last patch in the series can land, or bug 1533058 is fixed. But bug 1533058 got unassigned and now these patches are in limbo.

:whimboo, what's the way forward here? I would like this bug with r+'d patches and 17 dupes to get fixed soon before the patches bitrot. :-)

Comment 43

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to :Gijs (he/him) from comment #42)

:whimboo, what's the way forward here? I would like this bug with r+'d patches and 17 dupes to get fixed soon before the patches bitrot. :-)

Lets follow-up on bug 1533058 where I've just made a proposal, which I could try to finish today before heading on PTO for a week.

Comment 44

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Neil, your patch should be good to go. Can you please check? Thanks!

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0e738eb84828
create a special blank tab page that will show the bookmarks toolbar when 'Only Show on New Tab' is used' even when the new tab page is disabled, r=Gijs,Mardak
https://hg.mozilla.org/integration/autoland/rev/1ef480e93a6a
show the  bookmarks toolbar when a new window is opened when the preference is set to show a blank page, r=Mardak,settings-reviewers
https://hg.mozilla.org/integration/autoland/rev/2e7abedae4a0
when new tab page is configured to show a blank page, it should not be added to session history, r=Mardak

Comment 46

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/0e738eb84828
https://hg.mozilla.org/mozilla-central/rev/1ef480e93a6a
https://hg.mozilla.org/mozilla-central/rev/2e7abedae4a0

Comment 48

[:Gijs (he/him)]

Release Note Request (optional, but appreciated)
[Why is this notable]: Considering the 18 duplicates and because inevitably some other people who have the same setup as the 19 people who filed bugs actually like the current behaviour and will assume something is wrong when they suddenly get a bookmarks toolbar with their blank tabs that wasn't there before. Hopefully a release note will find at least some of those people.
[Affects Firefox for Android]: Nope
[Suggested wording]: The bookmarks toolbar's default "Only show on New Tab" state now also works correctly for blank new tabs. As before, you can change the bookmark toolbar's behavior using the toolbar context menu.
[Links (documentation, blog post, etc)]: n/a

Comment 49

[Andrej (:aglavic)]

== Change summary for alert #35974 (as of Fri, 04 Nov 2022 23:01:47 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
11%	twinopen ext+twinopen:twinopen.html	linux1804-64-shippable-qr	e10s fission stylo webrender	121.80 -> 108.19
11%	twinopen ext+twinopen:twinopen.html	linux1804-64-shippable-qr	e10s fission stylo webrender	123.27 -> 110.27

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=35974

Comment 51

[Monica Chiorean]

Reproduced the issue on Ubuntu 20.04, using FF build 85.0.
Verified issue on Ubuntu 20.04/Mac 10.13 / Win10 using 108.0(20221205155917), and confirmed the fix for steps 3 and 7 from description.
Step 5 from description still behaves the same - as mentioned on description (when custom page is set on 'Homepage and new windows', the newly opened new window does not display the bookmarks toolbar). Is this expected? Thank you.

Comment 52

[Neil Deakin]

The change in this bug makes the toolbar appear when 'Blank Page' is selected from either 'Homepage and new windows' or 'New tabs'. It shouldn't change the behaviour for any other of the choices.