1383599 - browser.newtabpage.enabled = false is not working

Status: RESOLVED FIXED

(Firefox :: New Tab Page, defect, P3)

Description

[Jason]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170723030206

Steps to reproduce:

1. Go to about:config
2. Toggle browser.newtabpage.enabled to false.
3. Exit about:config
4. Open a new tab.



Actual results:

A new-tab page appears, with a search bar and top sites listed.

However, every few times, it appears that following the four steps above actually does make the new-tab page blank, as it should.  But it mostly hasn't worked for me.


Expected results:

The four steps should have made the new-tab page completely blank.

Comment 1

[Jason]

So is Bugzilla the correct place to express this opinion?  Or Github?  Or Trello?

I ask because we are very concerned about this setting no longer working.  Our existing computers are currently using browser.newtabpage.enabled, and I really don't want to start hearing complaints from our teachers about this.

Comment 2

[Ed Lee :Mardak]

Design has said this isn't something to be done for firefox 57. A set of preferences can be used to turn off the various sections on the new tab page and they're available in the UI from the page.

Comment 3

[Jason]

This obviously isn't happening in 57, but is 58 still on track?

Comment 4

[Andrei Oprea [:andreio]]

(In reply to Jason from comment #3)
> This obviously isn't happening in 57, but is 58 still on track?

Firefox 58 is currently in Beta so we can't add any new work at this point.

I can help provide a workaround for this:
1. Deactivate activity stream from about:config by changing "browser.newtabpage.activity-stream.enabled" to false
2. Deactivate the newtabpage by changing "browser.newtabpage.enabled" to false

This will provide the expected result.

Comment 5

[Jason]

That will work for our managed machines, but we have many that are already deployed and unmanaged, and we don't have time to touch thousands of machines.

Is the fix still planned for 59?

Comment 6

[Andrei Oprea [:andreio]]

As of right now no. I'll ask about it and update the bug/status.

Comment 7

[Mike Connor [:mconnor]]

We should definitely fix this for Fx59, assuming it's going to be the next ESR release.

Comment 8

[Jason]

We have waited a while for this to be fixed and a few versions have been released since this was reported. Is 59 on schedule?

Comment 9

[Ed Lee :Mardak]

I suppose if we only expose browser.newtabpage.enabled via about:config, aboutNewTabService could just point at about:blank.

Where one main difference between tiles new tab and activity stream new tab is that tiles ran in the chrome process to have the page decide what it should show or not depending on .enabled, but activity stream requires a message to have the content page decide what to render.

A more involved fix for turning off browser.newtabpage.enabled would be to not use the prerendered page to render just the settings gear.

Comment 10

[Ed Lee :Mardak]

This has been prioritized as nice to have. Design said ideally this would be fixed as part of showing more new tab preferences from about:preferences.

Context being the only way to set the pref is via about:config although it doesn't really address comment 5.

tspurway, does comment 7 about 59 being an ESR release make any difference?

Comment 11

[Jason]

Would new tab preferences still set browser.newtabpage.enabled? browser.newtabpage.enabled has already been set in deployed machines, so having more settings in about:preferences would be neat, but short-term, I'd rather browser.newtabpage.enabled itself be fixed, regardless of whether there are formal controls for the setting.

Personally, I just want to revert to the behavior we had before browser.newtabpage.enabled was broken. Anything else is a bonus and distraction for me.

Comment 12

[Tim Spurway [:tspurway]]

browser.newtabpage.enabled does not completely disable the entire page in the legacy newtab page.  It can be turned back on in the gear menu.  This means that anyone who is using a machine with browser.newtabpage.enabled=false, can simply turn it back on by clicking a box in the gear menu.  For orgs that want to disable newtab functionality on multiple machines, this is not really an effective solution in the first place.

For activity stream to honour this pref would mean adding a lot of conditional/logic to multiplex browser.newtabpage.enabled onto the various sections of activity stream to achieve similar functionality to the legacy experience, as Ed alludes to in comment #9.  This is lots of tech debt for an incomplete solution to the outstanding problem.

Comment 13

[Jason]

For our purposes, the ability to turn the newtabpage back on via the gear menu is fine.  We have other protections in place to ensure these settings changes aren't permanent across reboots.

We just need the setting to work (even if it has the gear menu) so that we don't have to touch a bunch of already-deployed machines.  I don't think we will get complaints about just the gear menu, but we *are* getting complaints about the full newtab page being turned on by default.

In any case, I hope that this can be resolved quickly because I don't want to go yet another release of Firefox with this setting being broken.

Comment 14

[Ed Lee :Mardak]

There were some designs for UI https://trello.com/c/vRdK11r3/142-i-want-to-be-able-to-make-my-new-tab-blank-and-never-see-new-things

uiwanted: Is there something we can do short term, e.g., just load about:blank with no way of getting back until we get UI set up?

Comment 15

[Ed Lee :Mardak]

This should be fixed by bug 1417155 when there'll be an option to set new tab page to load default vs custom vs blank vs add-on. And to support blank, it would probably use this existing .enabled pref

Comment 16

[Ed Lee :Mardak]

Attachment: Bug 1383599 - browser.newtabpage.enabled = false is not working.

Review commit: https://reviewboard.mozilla.org/r/225740/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225740/

Comment 17

[Ed Lee :Mardak]

Comment on attachment 8956776 [details]
Bug 1383599 - browser.newtabpage.enabled = false is not working.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/225740/diff/1-2/

Comment 18

[Ursula Sarracini (:ursula)]

Comment on attachment 8956776 [details]
Bug 1383599 - browser.newtabpage.enabled = false is not working.

https://reviewboard.mozilla.org/r/225740/#review231702

Thanks for doing this Ed!

Comment 19

[Ed Lee :Mardak]

Comment on attachment 8956776 [details]
Bug 1383599 - browser.newtabpage.enabled = false is not working.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/225740/diff/2-3/

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/90ad57245468
browser.newtabpage.enabled = false is not working. r=ursula

Comment 21

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/90ad57245468

Comment 23

[Hlsg]

There seems to be a difference between what setting this to false generates and a pure "about:blank". The latter seems a bit faster and does not load the favicon while the former does.