Closed earthlng closed 7 years ago
Onboarding seems a first welcome BS:
pref("browser.onboarding.hidden", true);
pref("browser.onboarding.newtour", "");
pref("browser.onboarding.notification.finished", true);
pref("browser.onboarding.notification.max-life-time-per-tour-ms", 432000000);
pref("browser.onboarding.notification.max-prompt-count-per-tour", 1);
pref("browser.onboarding.notification.mute-duration-on-first-session-ms", 100);
pref("browser.onboarding.tourset-version", 1);
pref("browser.onboarding.updatetour", "");
Race Cache With Network
pref("network.http.rcwn.max_wait_before_racing_ms", 500);
is child of network.http.rcwn.enabled
This is good:
pref("security.data_uri.block_toplevel_data_uri_navigations", true);
And I set logging at minimum:
pref("services.sync.log.logger.engine.addresses", "Error");
I would if I knew what to do
pref("apz.autoscroll.enabled", false); pref("apz.frame_delay.enabled", false); pref("apz.keyboard.enabled", false); pref("apz.popups.enabled", false);
Safe to ignore : https://dxr.mozilla.org/mozilla-central/source/gfx/layers/apz/src/AsyncPanZoomController.cpp#125 ...138 ...281 ...288 ...356
pref("intl.regional_prefs.use_os_locales", false); Should be make inactive ? https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#2307 1364789
this pref allows user to request that all internationalization formatters like date/time formatting, unit formatting, calendars etc. should use OS locale set instead of the app locale set.
pref("network.preload", true); Safe to ignore : https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content 1222633
IMO, there is no privacy concern here.
// enables the preloading (i.e., preloading of <link rel="preload"> URLs).
pref("network.preload", true);
Is there a speculative aspect to that? Could there be cases where a web developer assumes a resource will be needed, but that resource isn't needed because of how the user interacts with the page or has their browser configured?
Could that interfere with any addons (create network traffic before they have the context they need to decide whether to block it)?
I don't see it included in network.networkPredictionEnabled:
// Add settings objects for supported APIs to the preferences manager.
ExtensionPreferencesManager.addSetting("network.networkPredictionEnabled", {
prefNames: [
"network.predictor.enabled",
"network.prefetch-next",
"network.http.speculative-parallel-limit",
"network.dns.disablePrefetch",
],
My first impression is that none of those would disable it. I need some caffeine, and your eyes may be better, so: https://dxr.mozilla.org/mozilla-central/source/uriloader/prefetch/nsPrefetchService.cpp. Followup: Quick tests in beta and nightly were consistent with my first impression.
Is there a speculative aspect to that?
Yes. On twitter 176 occurences are found, as:
<link rel="preload" href="https://abs.twimg.com/k/en/init.en.8aa0e9077608f68c80d3.js" as="script">
Is there a speculative aspect to that?
not per se afaik. Preload is used to load certain resources with a higher priority than it normally would. That can be used for SEO (=better pagerank for example) Of course it could also be used in a speculative way but that would defeat the purpose and would be kinda silly and counter-productive. The main problems that I could see are (1) with GM userscripts, (2) perhaps potential problems with CSP or certain origin attributes not being applied correctly in all cases, and (3) potential type-confusion problems/attacks.
pref("dom.disable_window_showModalDialog", true);
https://developer.mozilla.org/en-US/Firefox/Releases/56#DOM:
The Window.showModalDialog() method has been removed (bug 981796).
=> disabled with this pref in 56 and fully removed in 57 with 1374460 (they forgot to remove the prefs again though) => moved to 'ignored => new'
It's a recent feature: http://caniuse.com/#feat=link-rel-preload
What types of content can be preloaded?
Answer here.
I see it as a placebo to optimize hogged sites. Currently I'm on the opposite field, as keeping a local copy of some needed scripts for sites to load, while ignoring most of other resources.
If interested, see here.
56b12 changes since 56b1
pref("apz.second_tap_tolerance", "0.5");
pref("browser.tabs.restorebutton", 0); // new with value 'false' in Beta 1
pref("browser.urlbar.speculativeConnect.enabled", false); // new with value 'true' in Beta 1
pref("media.windows-media-foundation.use-nv12-format", false);
pref("network.http.throttle.time-window", 3000);
pref("services.sync.engine.bookmarks.validation.enabled", true);
pref("extensions.screenshots.system-disabled", true);
pref("geo.provider.ms-windows-location", false);
pref("apz.touch_move_tolerance", "0.1"); // prev: "0.03"
pref("browser.crashReports.unsubmittedCheck.enabled", true); // prev: false
pref("devtools.debugger.prefs-schema-version", "1.0.2"); // prev: "1.0.0"
pref("editor.use_div_for_default_newlines", true); // prev: false
pref("font.name-list.monospace.ja", "MS Gothic,...");
pref("font.name-list.sans-serif.ja", "Meiryo,...");
pref("font.name-list.serif.ja", "Yu Mincho,...");
pref("geo.wifi.uri", "https://location.services.mozilla.com/v1/geolocate?key=%MOZILLA_API_KEY%"); // prev: "https://www.googleapis.com/geolocation/v1/geolocate?key=%GOOGLE_API_KEY%"
pref("network.predictor.enable-prefetch", false); // prev: true // this was already changed in 55.0.1
pref("security.mixed_content.send_hsts_priming", true); // prev: false
pref("security.mixed_content.use_hsts", true); // prev: false
since the beta branch should have already been merged to release yesterday, I've update the first post with these latest changes.
moved to 'ignore' from 'new':
=> not messing with memory cache integer values
moved to 'ignore' from 'changed':
=> throttle is fine, and touch move tolerance ... who cares
update:
network.standard-url.punycode-host
- will be set to true in 57. This will be a pretty big change in how FF handles urls internally and we should definitely not mess with it. No need to enforce either - the pref will likely get removed again when they are satisfied that everything works as expected.
pref("dom.forms.autocomplete.formautofill", false); It's false by default and the system-addon will turn it on, but we already disable the system-addon, so why do we need this?
dom.noopener.newprocess.enabled - "Allow changing processes when opening a new window with noopener" - seems fine
gl.use-tls-is-current - Component: 'Canvas: WebGL' - ok to ignore
image.layout_network_priority - "image network request prioritization according to layout position" - I don't see a problem with that.
media.resume-bkgnd-video-on-tabhover - sounds good
network.http.active_tab_priority - "giving more priority to active tab" - sounds good to me
network.http.on_click_priority - "Give higher priority to requests resulting from a user interaction event like click-to-play, image fancy-box zoom, navigation." - sounds good
network.http.throttle.time-window - fixes problems with throttling - nice
extensions.webextensions.protocol.remote
https://bugzilla.mozilla.org/show_bug.cgi?id=1390346#c25
Yes, extensions.webextensions.protocol.remote=true is required for extensions to work now that file system read access sandboxing is enabled for content processes and the extension process. Setting it to false will require also setting sandboxing prefs to disable read access sandboxing.
The pref extensions.webextensions.protocol.remote was only added to aid debugging and provide a fallback shortly after moz-extension remoting was landed. If it's causing confusion, we could remove it. It has been helpful for debugging in a few instances.
https://bugzilla.mozilla.org/show_bug.cgi?id=1390346#c33
Does this pref serve a purpose? maybe we should get rid of it?
My preference would be to keep it for now because it's useful for debugging. Beyond debugging, it doesn't serve a purpose. And now that we've landed filesystem read access sandboxing, setting the pref to false requires flipping some sandbox prefs to get working extensions. That said, I've found it useful a few times while debugging extension issues.
https://bugzilla.mozilla.org/show_bug.cgi?id=1334550#c25
its expected lifetime is approximately the same as security.sandbox.content.level and I'd hope this can be removed once our sandbox is stabilized.
conclusion: best to ignore this
Last three all look like we can ignore them - agreed?
Yes
network.preload
I think is fine ie can be ignoredsecurity.data_uri.block_toplevel_data_uri_navigations
- sounds ready to be used in 56 but we can also wait for 57 where it will be set to true by default (most likely, it's already in the 57b3 diff)security.data_uri.block_toplevel_data_uri_navigations
- if there are still some issues wouldn't it be better to wait then? I'm on ESR so I don't really care - up to you.
btw please check if the prefs that we haven't ignored were actually set to the value the diff says, because I just noticed that they changed something with the omni.ja creation, and the order in which the default preferences files are loaded might have changed. Meaning that if a certain pref exists in 2 or more pref-files and with different values then the output of my diffs-script could be wrong for those prefs.
I'll adjust my scripts to detect the preferences files and their load-order automatically rather than hardcoded, which will also guarantee that I won't miss a new or split-out preferences file.
My only concern, because I am not an expert, would be that this could used on eg hyperlinks to 3rd party eg tracker)? IDK
<a href = www.evil.com?blahblah preload = true
whatever (scuse my shitty code example)
If trackers can get around extension-based blockers (or the built-in tracking protection) that way, then it's a bug that needs to be fixed :)
unless you meant that the first post should be accurate?
this. I was also wondering if maybe they messed something up which could result in the preferences files being loaded in an unintended order. But somehow it manages to load firefox-l10n.js after firefox.js even though as I understand the code it shouldn't. No idea why. Loading the files in a hardcoded order in my scripts seems to produce correct results though. I'll check with @Theemim once 57 is released to see if we get the same results.
it's all over my head mate, just askin' :)
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content
The
preload
value of the<link>
element's rel attribute allows you to write declarative fetch requests in your HTML<head>
<a>
tags cannot use preload!
Need a test site.
<body>
<script>console.log(navigator.connection);</script>
</body>
FF56 Desktop on Windows: dom.netinfo.enabled;false (default) : undefined dom.netinfo.enabled;true : NetworkInformation { type: "none", ontypechange: null } dom.netinfo.enabled;true + RFP : NetworkInformation { type: "unknown", ontypechange: null }
The transition to SBv4 will be gradual and done via a Shield add-on, which is disabled by user.js. So if you want to switch to it now, you can flip the prefs that the add-on will change:
https://github.com/mozilla/sbv4-gradual-rollout/blob/master/bootstrap.js#L16-L20
Otherwise you'll stay on V2 until either a 56 point release flips the prefs permanently, or 57 is released.
v55.0 vs v56.0
150 diffs ( 91 new, 28 gone, 31 different )
Firefox 56 stable lands 2017-09-28
new in v56.0:
extensions.formautofill.experimental
which is deprecated0810
removed, renamed or hidden in v56.0:
ALL DONE - https://github.com/ghacksuserjs/ghacks-user.js/commit/12f80bdf65910f039445eb9243c4f59434da5f77
1385201extensions.formautofill.available
and changed type from boolean to stringextensions.formautofill.available
can be "on", "off" and "detect"1386333changed in v56.0:
0413
1103
(inactive)2031
1110
redundant in 56 due to RFP privacy.resistFingerprinting
ignore
==NEW
==REMOVED or HIDDEN
==CHANGED