I see no point in keeping this to enforce a default that FF itself doesn't use - see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
- "... is an optional compatibility token that some Gecko-based browsers may choose to incorporate, to achieve maximum compatibility with websites that expect Firefox"
The last one-off ESR cycle of 8 releases is now behind us, new algorithm for FF60+ is back to 7 releases per ESR numbering, starting at 60... 67... etc. Note: This does not do anything for Aurora or Nightly spoofing the next ESR early (but we have until Nightly 67 before this becomes a problem). The ticket 1418162 was meant to cover this but instead was just used for the new algorithm. There is currently no ticket for the Aurora/Nightly issue - but never fear, Pants is here!! It is not forgotten, and I have emails with Tom Ritter et al on it
AS is out of control. No master switch in FF60+, and in order to 100% sure nothing is collected locally (or external connections made), there are now some 28 prefs (including those coming in FF61). This is re-DICK-ulous. We're not going to bother tracking all that, let alone the labyrinth of code. All users are advised to just make sure they remove the XPI every time they update FF.
2711 is about web extension data and does not fit in the 2700s is all about websites' persistent data, i.e items that sanitizing and Storage Manager deal with. Dumping in 2600's which is getting a revamp later
* Options> and [settings]
While I'm at it, I'm changing the 21 instances of
- `[SETTING-56+]` to just `[SETTING]`
- `[SETTING-ESR]` to `[SETTING-ESR52]` because we'll leave those in until 62 (yes I know they may apply to earlier ESRs, but people should be upgraded). Thus no ambiguity with ESR60 vs ESR52 users for the overlap
This is so wrong: It is better to inform users that 3 **must** be used than rely on zero info as well as removing useful info on what the values do. All future issues with this will be directed to earthlng. Remove RFP info as RFP users should know this stuff if they turned it on. Non RFP users, who we told they can bypass it, will not have a reference to RFP now. Enforce will now be banned as a word because, "reasons".
add `browser.storageManager.enabled` back but enforce it as true - otherwise people may never pick up on the fact we dropped it and may never reset it, and never see their shiny new UI section. When it's deprecated, *then* we can remove it
pref will be removed, 99% sure it was just a pref used internally to hide it from stable during testing in beta/nightly - see https://bugzilla.mozilla.org/show_bug.cgi?id=1428306. Makes zero sense to hide this new UI section since we will be turning SM on anyway (the section is important for end users to exist and be working esp thru QuotaManager and Storage v2 changes etc).
note: picked up a leading space on 2206. Please double check for any errors or missed opportunities (I scanned it three times), 1221 is about the only one that's a bit messy I think
Note: I moved the (part`x`) bit to the end of the bugzilla from previous commit as I like the https* bit to all be in line = visually easier to parse IMO
This is a start to reducing section 2600 (which I renamed it to just miscellaneous). We can always revisit this new section and add to it down the track if required. Note: added a second ref [2] under 0703. Note: re-numbered & re-positioned deprecated prefs for SPDY
These are all at default values, no need to enforce. As for removing them, we're de-cluttering the section and these just aren't that important. Anyone who wants to play with tab ordering/focus/etc could probably use an extension (API's?) and/or easily find these and look them up
geolocation blocking via RFP will be removed (see https://bugzilla.mozilla.org/show_bug.cgi?id=1441295), and since either way you look at it (those who use RFP or not) the user.js blocks geo, so we might as well move this stuff back to section 0200
1376865 was back ported to 59, so canvas prompt fatigue will be reduced. Note: the default for non-prompts is the same as if you clicked "Don't Allow" - i.e it serves up a 10x10px white square
Cleaning up the UA spoof stuff in the sticky, as a ticket was just closed (52 is now a temporary hard-coded value: 1418672 - I guess they're running out of time), so also cleaning up the info, and consistent layout
Two issues: The code to determine the ESR number is out of whack (by one) since the next ESR is 60. 59 stable is almost here. So they have decided to hard-code the value as 52, for now. The second issue is that Aurora/Nightly are ahead of stable/ESR and can thus unmask themselves as Aurora/Nightly. The hard-coded value for now also solves this.
If you follow the sticky for RFP, you will see there is a ticket for using the update channel information (eg stable, beta, dev, nightly etc) to determine when and how calculate the version spoof in future, and they'll also rejig the numbering algorithm to account for ESR being out by one. These are tickets https://bugzilla.mozilla.org/show_bug.cgi?id=1418162 and https://bugzilla.mozilla.org/show_bug.cgi?id=1428111
These default values are the same in all OSes and all current Firefox versions (ESR, Release, Beta, Nightly).
Apart from alerts.showFavicons these defaults are most likely never gonna change
data: works perfectly fine here. No need to use https and no need to connect to localhost because something could be listening there.
data is the fastest and best solution.
Note: I tested the value of 1 when changing from 2-block to make sure that it actually changed to allow in the panel. Am keeping my eye on the delete and backspace keys and will remove the line when it is fixed
You had it right the first time earthlng. Eg Start commits for 55-beta date shown is 9-July. 55-alpha release is dated 18-Aug and we drop the "-beta" part (look inside the release downloads). Start commits for 56-beta date shown is 12-Sept. 56-alpha release is dated 2-Oct and we drop the "-beta" part. And because you created the 57-alpha release before you reversed the date+version, that too is all good.
Controls the visibility of the "Options>Privacy & Security>Site Data" section.
I'd prefer to remove this completely because it only adds to the confusion about all the different storage types.
This is just an extension for localStorage (2705) with 3 methods: estimate(), persist() and persisted(). A site can ask for permission (?) to persist data which when granted basically just means that "Storage will not be cleared except by explicit user action" whereas otherwise when not persisted "Storage may be cleared by the UA under storage pressure." - I don't see a problem with that.
We'll keep 2706 inactive for now but might remove it in a future commit.
Sorry, but AFAIK, with this enabled it clears web extension storage when clear "offsite website data" is checked on close or manually (which we do in the user.js). Note also that even with this enabled, the UI settings are disabled, and the data-on-disk calculation never finishes, so at this point, its a bit useless to enable it until we figure that out. Will be back in 7 days
"Push and web notifications require service workers, which in turn require workers." - this is clearly not (or no longer) true. See #256 where workers are disabled, but service workers enabled, and service workers create IDB entries on Youtube
