Open Bug 1406088 Opened 2 years ago Updated 4 months ago

browser.newtabpage.rows (manually config reset at each restart)

Categories

(Firefox :: New Tab Page, enhancement, P5)

58 Branch
x86_64
macOS
enhancement

Tracking

()

UNCONFIRMED
Tracking Status
firefox57 --- wontfix
firefox58 --- fix-optional

People

(Reporter: alphascorp, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171005100211

Steps to reproduce:

Version info: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:58.0) Gecko/20100101 Firefox/58.0

I modify manually "browser.newtabpage.rows" : "3" to "5" 


Actual results:

At each close/start of Firefox my modification of "browser.newtabpage.rows" : "5" reset to "3"


Expected results:

the modification of "browser.newtabpage.rows" : "5" must stay "5" on each restart
OS: Unspecified → Mac OS X
Summary: browser.newtabpage.rows → browser.newtabpage.rows (manually config reset at each restart)
Component: Untriaged → New Tab Page
Hardware: Unspecified → x86_64
Definitely had this problem after browser.newtabpage.enhanced set to false.

On restart of firefox the browser.newtabpage.rows parameter is set back to default - 3.
browser.newtabpage.activity-stream.enabled;false

Results in the same bug. Worked around it on both my laptop and desktop by locking the preference (http://kb.mozillazine.org/Locking_preferences).

OS: Windows 10 Home and Windows 10 Pro respectively.

Firefox v57.0 (64 bit)
browser.newtabpage.activity-stream.enabled = false
browser.newtabpage.rows = 5

after browser restart set back to default value of 3

tested on firefox 57 (x64) on windows 10 and windows 8.1
This is caused by the migratePref() function call at line 144 of browser/extensions/activity-stream/bootstrap.js

The last line of the migratePref() function clear the user's preference:

Services.prefs.clearUserPref(oldPrefName);

It would be desirable to set the new value *without* clearing the old.

Related SuMo thread: https://support.mozilla.org/questions/1187487
Perhaps it would make sense to test for

browser.newtabpage.activity-stream.enabled = true

before calling migratePref()

That would allow users to benefit from the initial migration while not disturbing the custom preferences of those who switch

browser.newtabpage.activity-stream.enabled => false

and re-customize browser.newtabpage.rows to their tastes.

And it would avoid disturbing any subsequent customization of 

browser.newtabpage.activity-stream.topSitesCount

by users who prefer the Activity Stream layout and have left browser.newtabpage.rows at its default value.
The 'old' newtab page will very likely be removed along with all of it's settings in upcoming releases.
Severity: normal → enhancement
Priority: -- → P5
(In reply to Tim Spurway [:tspurway] from comment #6)
> The 'old' newtab page will very likely be removed along with all of it's
> settings in upcoming releases.

Well, this sucks, unless the 'new' new tab becomes as customizable as the previous one. I'm using the old one because I find the new version rather ugly and difficult (if not impossible) to set up.
You need to log in before you can comment on or make changes to this bug.