ToDo: diffs FF53-FF54 #87
Comments
|
|
|
Nice work @earthlng. Those looks promising for "lite" version for FF 54+: Assuming that I need to trust some entity, switching those to mozilla servers instead of google is a good thing... at least I also have current (the google ones) to false now. |
|
Thanks @crssi In a "lite" version we would probably enable safebrowsing and trackingprotection and therefore not change those 4 prefs, but since we don't have different versions at the moment and since we have the 2 "old" prefs already set to empty string (browser.safebrowsing.reportMalwareMistakeURL + browser.safebrowsing.reportPhishMistakeURL), we will most likely also set the 4 new prefs to empty string in the master user.js. |
|
new sanitized pref for FF54 user.js: user_pref("extensions.blocklist.url", "https://blocklists.settings.services.mozilla.com/v1/blocklist/3/%APP_ID%/%APP_VERSION%/"); |
|
I understand... we are on exactly "on the same page" here. :) |
yeah, maybe. let's ignore it for now and wait until stable is released and then we can see if the pref is still there |
|
If you don't mind my asking, what do you use for calculating the differences between releases. I use Linux and would like to keep a track of the pref changes on this platform. Thanks |
custom scripts |
Thanks for the information. I for one wold be very interested in seeing the Linux prefs added but I don't wish to present you with additional work if the demand is low. |
they are all stable afaik, what do you mean? Tell me which versions you want compared and I can do it.
IDK, its usefulness is pretty limited, and I already link to the files there in every ToDo: diffs issue, but feel free to add it if you want
@Radagast, this will have to do for now, sorry. Apart from the few prefs listed there, the large majority of prefs is the same for Linux and Windows. |
|
Well, in ESR not too many things change between the minor versions (fe. 52.0 to 52.1.0) /******************************************************************************************
* diffs between FF prefs v52.0esr and v52.1.0esr
******************************************************************************************/
// changed in v52.1.0esr:
pref("network.predictor.enable-prefetch", false); // prev: true
pref("security.pki.certificate_transparency.mode", 0); // prev: 1At some point there will be massive changes when all the old stuff gets removed and the new stuff added, but atm I'm not sure when exactly that is normally happening. |
|
Does anyone know what |
|
Thanks for looking into it. I did not expect you take a deep dive. I only thought to ask because at some stage it was added to the user.js before the upload to github. Look what I found relating to funnelcake: https://bugzilla.mozilla.org/show_bug.cgi?id=1322718#c1 (at the top is a link to a google doc) PS Thanks for the invite. I can't promise much involvement though. |
|
Looks like yes. I looked at https://bugzilla.mozilla.org/show_bug.cgi?id=1289231 and It looks like EDIT: fixed link. |
|
If It's user initiated why is it called automigrate? It's in the Personal Settings section and I'd like to keep it there and not remove it. I'm assuming it's still possible to import settings etc from other browsers even with this set to false. And I doubt that someone who switches to FF will do so with this user.js right from the get-go. Once they find this they'll have their settings, bookmarks, etc already imported from their old browser. |
This is a pref to hide a UI doorhanger which allows an end user to KEEP or UNDO auto-migrated "stuff" from another browser (eg from IE etc). This is part of funnelweb, which is an upcoming makeover of the "onboarding experience" (to retain users in a new FF) - this includes auto-importing their bookmarks etc from another browser in the background and THEN asking if they want to keep them or undo. We cannot block the UI to this for obvious reasons. Funnelweb also includes this like a new Tour UI, activity streams etc https://bugzilla.mozilla.org/show_bug.cgi?id=1297479 https://bugzilla.mozilla.org/show_bug.cgi?id=1322718#c1 Tour thingy: https://www.ghacks.net/2017/03/31/firefox-photon-new-design-mockups-show-interface-and-more/ Activity Streams: https://www.ghacks.net/2017/04/09/firefox-57-photon-mockups-activity-stream-library-compact-mode-more/
|
|
|
|
@earthlng A note here, as I modify any child entry even if the main ones has been modified, e.g. |
|
expire_days = 0 (?) or 1 is what you want in that case btw rather than 999 ;)
yes, I saw that in your fork :) but we would end up with hundreds of additional prefs if we did that. We want to make this user.js easier to use and adding dozens or even hundreds of additional "unnecessary" prefs would be the opposite of that |
|
changes in beta11 since the beta1 diff in OP: NEWpref("extensions.screenshots.system-disabled", true); - f61c951 (note, thorin already added this one item to the first post) CHANGED
|
|
They had to "Revert back to using a pref for the moment" because the older patch (without a pref?) caused a crash and had to be backed out.
I think the Nightly behavior is preferable because allowing "out-of-spec" data parsing is probably never a good thing other than not to "annoy too many users". They also mention that
But they also say
"in general" - well okay - maybe worth considering adding this and set to to "true"
IMO no need to add this to the user.js |
IMO every pref in the user.js with the same value as the default value in FF should be active. |
@earthlng while I get your point I disagree. By not forcing every default pref we allow the user to change some settings via the FF GUI granted some could be set to less private/secure by the user. Also I'm lazy so if I don't like a pref I don't need to change as many 😛. For me I like that can look at the user.js and I know that all the used prefs that are in use differ from the FF default (i.e. I know what improvements are made through the user.js) |
|
|
|
|
// Allow Flash async drawing mode in 64-bit release builds
pref("dom.ipc.plugins.asyncdrawing.enabled", true);
// Force the accelerated direct path for a subset of Flash wmode values
pref("dom.ipc.plugins.forcedirect.enabled", true);Flash stuff - who gives a fuck?!? If people still use that piece of shit that's not my problem. |
afaik setting it to false would make things worse. Look at the TBB ticket you linked again. This pref does something but it's not about precision or imprecision. Hopefully they'll bring back |
|
|
|
changes in FF54 Release since the beta1 diff in OP (bold = changes since beta13): NEWpref("extensions.screenshots.system-disabled", true); CHANGED
|
// This is referred only when both "intl.tsf.enable" and "intl.tsf.support_imm"
// are true. When this is true, default IMC is associated with focused window
// only when active keyboard layout is a legacy IMM-IME.
pref("intl.tsf.associate_imc_only_when_imm_ime_is_active", false);
// Whether default IMC should be associated with focused window when MS-IME
// for Japanese on Win10 is active. MS-IME for Japanese on Win10 has a crash
// bug. While restoring default IMC when MS-IME for Japanese is active,
// it sometimes crashes after Creators Update. This pref avoid the crash.
pref("intl.tsf.hack.ms_japanese_ime.do_not_associate_imc_on_win10", true);If you agree that we can ignore these 2 then we can close this and you can release an alpha. edit: I think this is the bugzilla for those 2 but it's |
v53.0 vs v54.0
119 diffs ( 54 new, 55 gone, 10 different )
new in v54.0:
removed, renamed or hidden in v54.0:
Done - see 82432a3
13423611242321changed in v54.0:
pref("extensions.blocklist.url", "https://blocklists.settings.services.mozilla.com/v1/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/"); // prev: "https://blocklist.addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/"=> Migrate the blocklist preferences to new URI
ignore
==NEW
==REMOVED or HIDDEN
==CHANGED
The text was updated successfully, but these errors were encountered: