- FF85+ switched to using application regional locale
- go to about:support > Internationalization & Localization (almost at the very end)
- look at Application > Regional Preferences
- add test
updating (app, extensions, ext cache) is not a privacy issue
- if you're willing to use Firefox but not trust updating, then I have two bricks to sell you: users who wish to disable it (to check changes first etc) and update in a timely manner, then that is on them - including any prompt fatigue
- same goes for extensions: the end-user installed them (and arkenfox only recommends a very select few) - the onus is on the end-user
The remaining ones I will deal with later
auto-updating is not a security nor a privacy risk, by default it should be enabled and it's on end-users if they want to disable it - does not affect windows users
- they require SWers which are already blocked by virtue of permissions being session only
- also remove "dom.push.userAgentID" as this means prefsCleaner resets it and would wipe user's subscriptions
- not adding "dom.push.userAgentID" to the cleanup script for the same reason
currently 3rd party service workers are blocked in FF95 when dFPI is enabled (which this version has should anyone update to 96-alpha)
- but I get an error even on first party - https://arkenfox.github.io/TZP/tzp.html#storage
- I get : service worker | test : enabled | failed: SecurityError
in FF96+ service workers they are covered by dFPI
- see https://bugzilla.mozilla.org/show_bug.cgi?id=1731999
we've never used these
- service workers are disabled (or soon to be covered by dFPI when enabled) and sanitizing is already done (or will be done via enhanced cookie cleaning)
- storage API, storage access API: we sanitize on close, and sites are isolated by eTLD+1
- in v94 we switched to cookies lifetime as session, so users could use site exceptions to retain selected cookies (to stay logged in one assumes)
- that mean not deleting all cookies on shutdown
- but some login methods/types require more than cookies and also need the "site data" part of "cookies + site data" - that's the offlineApps part
- note: all site data (and cookies) is still cleared on close except site exceptions
FYI: https://bugzilla.mozilla.org/1738372
There is a small privacy issue with shoulder surfers, but in reality, this just needs to happen IMO
- we already prompt where to save, but even if we didn't, we also know we clicked or initiated a download
- unless it's a drive by or user-gesture trickery - which is why we prompt
- the download icon is shown (if hidden) and the throbber/accent color go to work
- users can always click the icon to show entries (and open folder etc)
- this maintains the current behavior in FF94
anti-fingerprinting doesn't fit here: it's not a major component or priority of this user.js, and only a few prefs outside RFP (as a robust built-in browser solution that defeats naive scripts) have anything to do with it
move all sanitizing on exit prefs into 2800
switch to cookie lifetime as session
- now users can utilize exceptions (as allow)
- session cookies still block service workers (which we disable anyway)
- we still block 3rd party cookies (until we move to dFPI)
- we still have defense in depth for 3rd party cookies with 2803
- we still bulk sanitize offlineApps on exit: localStorage, service worker cache, QuotaManager (IndexedDB, asm-cache)
- i.e you get to keep the cookies only IF you add an exception
add `privacy.clearsitedata.cache.enabled`
The point was that google have said (stated in policy, but fuck knows where that is located these days) that it is anonymized and not used for tracking. It's an API used by **_4 billion devices_** - the API has privacy policies for use. If a whistleblower or someone else found out that google was using this to enhance their user profiling, then all hell would break loose. And they don't even need this to fuel their ad revenue. It is provided, gratis, to the web to help ensure security - they wouldn't dare taint it and get it caught up in a privacy scandal involving **+4 billion devices_**. And in all this time (since 2007), there has been no such whistleblower or proof it is used to track or announcements by google of changes to the contrary.
Anyway, a quick search brings up
- Here is their policy - https://www.google.com/intl/en_us/privacy/browsing.html - it's empty and points to
- https://www.google.com/intl/en/chrome/privacy/
- and if you scroll down to "Safe Browsing practices" it doesn't say anything about privacy policies for the API itself (or the owner of the API) - it just spells out what happens in chrome
- I'm not going to bother to look any further and find a history of policy changes
Anyway, this is Firefox and hashes are part hashes bundled with other real hashes - and we turned off real time binary checks. So this line can fuck the fuck off. It was meant to reassure those who want the security of real-time binary checks, that privacy "shouldn't" be an issue, but I'm not going to expand on it
- and remove obsolete ESR78 notations
- note: we leave the deprecated ESR78.x section and item 6050 until v95 so users upgrading to ESR91 can easily reset those prefs with prefsCleaner
- this helps mitigate the need for scratchpad for those who use prefsCleaner
- in future, if anything was active during the ESR cycle, then it goes in here when removed
- similar to deprecated items: clean out after ESR EOL
- I am no longer short one parrot
- move inactive screenshots to personal
- move FORM autofill to `0800... FORMS` - can't find it now, but this is slated to cease being a system addon and instead be "built-in"
- the rest will get swallowed into a revamped, split QUIETER FOX
- there was only one perf left
- warning is down to 5: two in section headers, 3 on inactive prefs: no need to mention it, people will see them if they read each item/section
More minor tweaks to come. This isn't final
- 0102: ambiguous that the clearing was related to PB mode
- 0900s:
- get rid of 0901, it has no pref, stick link in header
- 0905: values on multi-lines use spaces = more readable
- 1000s:
- rename as disk avoidance and remove sub-section headers
- remove the outdated section header
- 4001: it will never be perfected, it's doing it's job
- 5500s: optional hardening
- legit security measures, but commonality in caveats, so I made them a separate section
- this flips graphite, asm.js and wasm from active to inactive: these are overkill: exhibit A: hundreds of millions of Firefox users
- e.g. graphite and wasm are enabled on Tor Browser
- new CVE keyword links
- 7000s: don't bother - two more items added
- 5000s: optional opsec and cleanout 0800s header
- re-number
- 0900s, 1000s, 1400s, 2400s
PS: I need a new parrot: "9000 syntax error: I ran out of parrots"
Yes it's pretty much useless. Yes it's fingerprintable, and what that entropy is, who knows. Since it's sent regardless with ETP, which we enable in all windows, then who cares. And if you don't use ETP in all windows, then I don't care either - just saying
probably more professional to keep it at the end since it isn't strictly project related. It also opens up space for `DON'T TOUCH` and `OPTIONAL OPSEC`
- merged 3DES cipher to bottom: it is still the same order of [1]
- 3DES pref will be deprecated: pref name changes, and the cipher slated to be unavailable unless you downgrade to < TLS1.2 - see https://bugzilla.mozilla.org/show_bug.cgi?id=1724072
- FYI: we reset TLS downgrades to session only by resetting the pref currently in 1203
- "Minimal/non-existent threat of downgrade attacks"
- FYI: these old ciphers are about 1-2% of traffic (from memory) - but that's still significant breakage
- So the only reason to do this would be to harden against downgrade attacks (and inadvertently use weak sites = breakage): but that doesn't fit most user's threat model: and is probably never going to happen for them. Not sure if I can word that much better and just as succinct
- inactive in user.js since
- v55: gfx.direct2d.disabled
- v67: layers.acceleration.disabled
- the way to counter hardware fingerprinting is within each API that may expose it
- this may have made some sense way back in the day, when there were less options/protections, but not any more
- [are we web render yet](https://arewewebrenderyet.com/) - yes, 100% - there is no need to cripple your browser's perf
- inactive since we added it in v63
- this is not how you defeat fingerprinting (unless done in an enforced set)
- for the record: not even tor browser disable this
- fingerprinting this is not cheap in gecko (for now)
- from [2]
- decoding/encoding capabilities: "it is expected that the entropy ... isn’t going to be significant"
- HDR detection: "... has the potential to add significant entropy .. however .. but ... thus minimizing effective entropy" - it is what it is
- note that RFP has some mitigations in FF82+ 1461454
- just to be clear, this section is not supported: not interested in references or explanations or FF version numbers or default info etc
- "do more harm than good" - ambiguous, not interested in explaining why exactly: but FYI
- some leak
- most break shit
- almost all are easily fingerprinted and the combo of them would make you really stand out
- removed the duplicate `ui.prefersReducedMotion` - this should move to personal as well
- moved `ui.systemUsesDarkTheme` to personal
8000s (was 4600s)
- move below personal, so user-relevant part is shorter
- swap out font vis with document fonts + font whitelist
- font vis still has usability/visual purposes: it just won't really help much with fingerprinting
- ESR78 users (who can't use font vis), sorry, but we made doc fonts inactive for a while now, and now recommend you don't use it anyway
- dead weight since 2017-06-13 when ESR45 reached EOL .. good riddance
- if someone does use it, it's not going to do any harm, so no need to carry it for prefsCleaner
- geo -> warning
- merge container prefs
- remove redundant "see"s
- remove corresponding 4600's item number in RFP mitigations
- it's pretty clear by the preference names in 4600
- could be misconstrued that the 4600 pref is the same result
- RFP's language prompt only checks for en*, not en-US (so en-GB, en-CA etc do not get prompted)
- https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPHelper.jsm#196
- 0105*: merge into a single block
- 1220: make values more readable with spaces, like 2701 (no need for value 2), add default, update advise (get a new AV, SHA1 is dead baby)
- 2619: remove fluff
- we already disable webgl, that's enough
- the other two prefs are not going to provide much protection if a user decides they want webgl
- "disable-fail-if-major-performance-caveat" only applies to ESR78 and will removed in the future
- one (or two) less pref(2) for users to troubleshoot/flip
- remove 2720
- this is a very old pref, been inactive since at least our first github release: v51
- disabling the API is not how you control client side state: you do that by blocking cookies which also controls other state such as IDB etc
- 2700 section header
- history/downloads is redundant
- Offline Website Data info -> relevant item number with Active Logins info
- ^ technically it still includes appCache for ESR78 users, but that will be moot in less than three months
- tidy RFP
- update to FF91 userAgent spoofing: there is no Android ESR so we don't need to mention "Android 9"
- we don't need to say if the API is enabled for mediaDevices
- the service implies a check is done first, I'm more concerned with the actual updating: not that updates are bad, it's about controlling when (if ever e.g. my test suite)
- since 0301 has to be done manually in Windows, 0302 is a good fallback **IF** the background service is applicable (read the link)
- clean up the numbering
- "enforce" is for when we set the default value
- use [WARNING] for inactive (they're inactive for a reason and people really do not need to turn them on) but less scary [NOTE] for active (tweak away at your own risk)
- seems neater, easier and less scary for users setting up the first time: i.e they only need to initially look at active items
- FYI: I was going to add something to LSNG (2760) that it is required for Fission, but will wait, and it struck me that 2680 was the only active item with a warning: seems inconsistent
- 2684: security delay .. make enforce mean enforce (default) ... not worth occasionally saving .3 seconds
- for now it's one less item in differences/flips
- might make this inactive in 91+, and add a warning
- it has been a very long time since we added this due to bad advise/references on the internet on how to speed up Firefox
- add -s parameter to start immediately / skip prompt / run non-interactive
This is useful if the user wants to automate the process of updating the user.js and cleaning prefs.
- fQuit: error messages to stderr
- fFF_check: info msg to stderr
Better support for suppressing/redirecting stdout while still showing any error messages in the console, useful for example with `prefsCleaner.sh -s >/dev/null`
- re-arrange the match patterns to fix the remaining issue of dropping lines after the 9999 block
- make it work on Mac too
- use `|` where possible so we don't need to escape the forward-slashes. That saves a few bytes and makes the pattern easier to read
see #1188
this should fix the issue that "All prefs after a multi-line comment declaration, on a single line, are deleted with the remove_comments function from the updater."
- they all have on/off switches
- dxr no longer exists: update URL
- don't recommend users delete files
- saves two lines
- they poses zero threat (they have prefs)
- deleting them can causes unwanted console errors/noise
It literally cannot hurt [1], and makes it easier for users to use custom mode with TCP/dFPI. Turning on socialtracking helps gain parity with strict mode
[1] gorhill: https://old.reddit.com/r/firefox/comments/l7xetb/network_priority_for_firefoxs_enhanced_tracking/gl9rn9n/
> All extensions and ETP work in parallel, they all inspect network requests and all make the decision to block or not, hence if they all decide to block, they will all report that they block something. ETP is a bit different than normal extension in that it will give precedence to an extension trying to redirect to a local resource, this ensures ETP works harmoniously with normal extensions.
>
> Once something is not blocked, it then goes through a DNS query, and the browser waits for the response.
>
> I will add examples of how ETP + multiple blocker extensions work together when dealing with a network request; let's say "A" and "B" are two different blockers:
>
> - ETP=block, A=allow, B=allow: result=block
> - ETP=allow, A=block, B=allow: result=block
> - ETP=allow, A=allow, B=redirect: result=redirect
> - ETP=allow, A=block, B=redirect: result=block
> - ETP=block, A=allow, B=redirect: result=redirect
>
> So as you can see, ETP is a bit different than a normal extension in that it won't prevent redirection from happening if ever a network request is redirected by one of the normal extension.
It is simpler to leave the PointerEvent pref where it is, until ESR78 is EOL
- FF87+ users who use RFP Alts simply add a dead pref, no harm
- This way ESR78 users don't have to worry about extra char flipping: it's the same as before: 1 flip for ESR, 1 flip for RFP Alts
only stable is false, at the time of writing. but enforcing this for all channels is good, so no-one ends up wasting mozilla resources reporting a compat problem when they've got 200 odd prefs flipped
- don't differentiate between channels
- both can be made inactive
- webcompat requires user action: and I don't see this as a bad thing to have in non-stable
- unsubmitted crashReports on Nightly is probably already covered by killing the URL, so no big deal
- 0000: remove old XUL info, dropped in FF73+
- 0201: save 3 chars
- 0350: add default status for unsubmittedCheck
- 0351: change to enforce: has been default false going back to at least FF60, including current Beta/Dev/Nightly
- along with 0602 `network.dns.disablePrefetchFromHTTPS` and 0603 `network.predictor.enable-prefetch`, I considered making them inactive, but decided it was good to leave them active for non-stable users just in case they get flipped
- 0515: add default status
- 0850c: remove info: out of date: doesn't work lilke that anymore and can't be assed figuring it out what with megabar and urlbar2 changes
- 0871: make inactive: default false since at least FF60
- no need to enforce for non-stable in case it is flipped. It's a pretty minor shoulder-surfer privacy issue and the previews are small. If you're not sure what this pref does. On false you get one tab shown, on true you get as many as can fit across your screen. I squeezed in 15, and after that it became a list
- fixup `***/`
- shave off six lines and almost 400 bytes for you bastards
- This is too minimal to be of any use, breaks too much (e.g. zoom video)
- Tor browser stopped flipping this (I *think*) about 5 years ago: it certainly hasn't been used in ESR60+ based TB builds, I checked
- we already disable webgl, so making this inactive removes yet another pref users need to flip/troubleshoot
- I will leave it in the user js for a few releases so prefsCleaner will pick it up
- It is controlled in both runtime and via user.js by the state of `media.eme.enabled`. Also, who cares about the vis of a ui option
- note, there is no need to add this to the removed scratchpad list
cmd.exe has a command line length limit of 8192 characters. Abort if prefs.js contains strings that would get dropped while recreating the new prefs.js.
`browser.newtabpage.activity-stream.asrouter.providers.snippets`
These (which landed in FF64 with snippets above) are not in the user.js, so why bother with the snippet one
- `browser.newtabpage.activity-stream.asrouter.providers.cfr`
- `browser.newtabpage.activity-stream.asrouter.providers.onboarding`
also these aren't in the user.js
- `browser.newtabpage.activity-stream.asrouter.providers.cfr-fxa`
- `browser.newtabpage.activity-stream.asrouter.providers.message-groups`
- `browser.newtabpage.activity-stream.asrouter.providers.messaging-experiments`
- `browser.newtabpage.activity-stream.asrouter.providers.whats-new-panel`
There are no privacy concerns here. At the end of the day, what Firefox connects to and sends is E2EE and only used locally in non-web content: and you have other prefs and a UI to disable them from being displayed
- remove useless `see` word for reference links
- fixup 0701
- "do not play nice" is not measurable
- don't reference to self as a source: people can just search "VPN leak Ipv6" or something
- shrink and remove outdated info from section 0300 header
- combine some bugzillas
- drop some references
- 1647829 for HTTPS-Only mode
- hardware metrics: not going to implicitly encourage users to use this pref or tell them what sizes to use
- update [STATS]
- also remove TLS [STATS].. stats on TLS 1.0 and 1.1 are irrelevant: the default is now TLS 1.2+
- single CRLite reference for all blog articles
- save 588 bytes so all you bastards can theoretically load Firefox just that tiny bit faster
Note
- this is not the same as 2517 which disables the API
- RFP does not determine what is supported or not supported: so that entropy remains
- with or without RFP, if the media config is not supported it returns false,false (so there is nothing to spoof here)
* misc
- cleanup of old release notation in comments: e.g. if it's not applicable to ESR78+
- same with default version info
- simplify and save bytes on section 4700
- update 4500 header
- and unify the message about using extensions as counterproductive
- letterboxing
- provide info on stepped ranged (and drop crap about FF67)
- don't judge users who dislike seeing margins (I don't like them either, but I force my window to exact dimensions and stay there)
- screenshots uploading was disabled in FF67+ : [67 release notes](https://www.mozilla.org/en-US/firefox/67.0/releasenotes/)
- the pref is still there (default false) but so far I'm 99% sure this pref now does anything
- I will add it to the scatchpad script if this change sticks
* simplify 4500 RFP, see #1041
* update removed script
* tidy readme, see #1045
- also put readme before releases
* RIP FX Site Compat
* clean out RFP Alts info: the information is redundant: it's already in the readme
- make 1401 inactive: it affects RFP's FPing
- remove old warning/setup-web: we do not care about documenting breakage or FPing risks when we have a warning and they are inactive. If someone uses them, that's on them
- new warnings
- this was made inactive in v68
- since at least FF79, when active as false, it breaks the web and browser consoles
- it breaks websites
- it breaks extensions: e.g. uBO panel functionality
- it does nothing to mitigate possible fingerprinting (which was why it was initially added as a concern) - i.e the API only provided a standardized method, it does not stop previous/earlier workarounds
* 0 : successful termination
* 2 : command line syntax error
* 1 : catchall for general errors
Plus a few text improvements based on unmerged PR 4fbb2be98d
- less active prefs
- now that ESR68 is EOL, at least a whopping two (0602, 1273)
- also I don't know when the default changed - another whopping whole one (1240)
- and where we do enforce/reset a pref to default, lets say that
- this is not a definitive list, sing out if there is anything else
- IPv6 info
- especially for Iron Heart who likes to claim that this pref breaks 5% of sites
- cleanup of settings tags now we only care abut ESR78+
* rework DOWNLOAD_METHOD, download_file, open_file
* remove legacy command leftover line
* return empty string if download fails and return/exit if this happens and show error message
* fix IFS var typo
* bump version
* add quotes
Co-authored-by: TotallyLeGIT <bbkqx24kxlgvgbss@mailban.de>
- Go to https://telemetry.mozilla.org/
- click `measurement dashboard`
- select `SSL_HANDSHAKE_VERSION`
I looked at Nightly 75 (0.26 and 0.01) and Nightly 76 (0.2 and 0)
We value feedback in general, but we value feedback from informed users more. There is no need for you to be an expert to participate (most of us aren't), but we hope that you at least understand our decisions before questioning them. We discuss all changes openly, and we do not make changes lightly. So, if you don't understand why we decided to add/remove/change a certain pref, search the repo. The answer is most certainly here.
If some change we made took you by surprise (in the wrong way), remember that keeping track of changes is your responsibility. Watch the repo, read the [changelogs](https://github.com/ghacksuserjs/ghacks-user.js/issues?utf8=✓&q=is%3Aissue+label%3Achangelog), compare [releases](https://github.com/ghacksuserjs/ghacks-user.js/releases) as you update your copy of user.js, or use any other method you prefer.
If some change we made took you by surprise (in the wrong way), remember that keeping track of changes is your responsibility. Watch the repo, read the [changelogs](https://github.com/arkenfox/user.js/issues?utf8=✓&q=is%3Aissue+label%3Achangelog), compare [releases](https://github.com/arkenfox/user.js/releases) as you update your copy of user.js, or use any other method you prefer.
A `user.js` is a configuration file that can control hundreds of Firefox settings. For a more technical breakdown and explanation, you can read more on the [overview](https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.1-Overview) wiki page.
### 🟪 user.js
A `user.js` is a configuration file that can control Firefox settings - for a more technical breakdown and explanation, you can read more in the [wiki](https://github.com/arkenfox/user.js/wiki/2.1-User.js)
### ![][b] ghacks user.js
The `ghacks user.js` is a **template** which aims to provide as much privacy and enhanced security as possible, and to reduce tracking and fingerprinting as much as possible - while minimizing any loss of functionality and breakage (but it will happen).
### 🟩 the arkenfox user.js
Everyone, experts included, should at least read the [implementation](https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.3-Implementation) wiki page, as it contains important information regarding a few `ghacks user.js` settings.
Note that we do *not* recommend connecting over Tor on Firefox. Use the [Tor Browser](https://www.torproject.org/projects/torbrowser.html.en) if your [threat model](https://www.torproject.org/about/torusers.html.en) calls for it, or for accessing hidden services.
The `arkenfox user.js` is a **template** which aims to provide as much privacy and enhanced security as possible, and to reduce tracking and fingerprinting as much as possible - while minimizing any loss of functionality and breakage (but it will happen).
Also be aware that this `user.js` is made specifically for desktop Firefox. Using it as-is in other Gecko-based browsers can be counterproductive, especially in the Tor Browser.
Everyone, experts included, should at least read the [wiki](https://github.com/arkenfox/user.js/wiki), as it contains important information regarding a few `user.js` settings.
Note that we do *not* recommend connecting over Tor on Firefox. Use the [Tor Browser](https://www.torproject.org/projects/torbrowser.html.en) if your [threat model](https://2019.www.torproject.org/about/torusers.html) calls for it, or for accessing hidden services.
### ![][b] acknowledgments
Literally thousands of sources, references and suggestions. That said...
Also be aware that the `arkenfox user.js` is made specifically for desktop Firefox. Using it as-is in other Gecko-based browsers can be counterproductive, especially in the Tor Browser.
* Martin Brinkmann at [ghacks](https://www.ghacks.net/) <sup>1</sup>
* The 12bytes article now uses this user.js and supplements it with an additional JS hosted at [Codeberg](https://codeberg.org/12bytes.org/Firefox-user.js-supplement)
### 🟧 sitemap
<sup>1</sup> The ghacks user.js was an independent project by [Thorin-Oakenpants](https://github.com/Thorin-Oakenpants) started in early 2015 and was [first published](https://www.ghacks.net/2015/08/18/a-comprehensive-list-of-firefox-privacy-and-security-settings/) at ghacks in August 2015. With Martin Brinkmann's blessing, it will keep the ghacks name.
mv prefs.js "${bakfile}"|| fQuit 1"Operation aborted.\nReason: Could not create backup file $bakfile"
echo -e "\nprefs.js backed up: $bakfile"
echo"Cleaning prefs.js..."
fClean "$bakfile"
fQuit 0"All done!"
fStart
;;
Help)
fUsage
echo -e "\nThis script creates a backup of your prefs.js file before doing anything."
echo -e "It should be safe, but you can follow these steps if something goes wrong:\n"
echo"1. Make sure Firefox is closed."
@ -90,7 +105,7 @@ select option in Start Help Exit; do
echo"4. Rename or copy your latest backup to prefs.js."
echo"5. Run Firefox and see if you notice anything wrong with it."
echo"6. If you do notice something wrong, especially with your extensions, and/or with the UI, go to about:support, and restart Firefox with add-ons disabled. Then, restart it again normally, and see if the problems were solved."
echo -e "If you are able to identify the cause of your issues, please bring it up on ghacks-user.js GitHub repository.\n"
echo -e "If you are able to identify the cause of your issues, please bring it up on the arkenfox user.js GitHub repository.\n"
if(confirm("if the problem still exists click OK, otherwise click cancel.")){
alert('NOW TEST AGAIN !');
if(confirm('if the problem still exists click OK, otherwise click Cancel.')){
aTmp=aTmp.slice(_h(aTmp));
}else{
aTmp=aTmp.slice(0,_h(aTmp));
@ -182,16 +175,16 @@
if(aDbg.length==1)returnalert("narrowed it down to:\n\n"+aDbg[0].name+"\n");
if(aDbg.length==aALL.length){
letmsg="Failed to narrow it down beyond the initial "+aALL.length+" prefs. The problem is most likely caused by at least 2 prefs!\n\n";
msg+="Either those prefs are too far apart in the list or there are exactly 2 culprits and they just happen to be at the wrong place.\n\n";
msg+="In case it's the latter, the script can add a dummy pref and you can try again - Try again?";
constmsg="Failed to narrow it down beyond the initial "+aALL.length+" prefs. The problem is most likely caused by at least 2 prefs!\n\n"+
"Either those prefs are too far apart in the list or there are exactly 2 culprits and they just happen to be at the wrong place.\n\n"+
"In case it's the latter, the script can add a dummy pref and you can try again - Try again?";
if(confirm(msg))return_main([...aALL,oFILLER]);
}elseif(aDbg.length>10&&confirm("Narrowed it down to "+aDbg.length+" prefs. Try narrowing it down further?")){
return_main(aDbg.reverse());
}
alert("Narrowed it down to "+aDbg.length.toString()+" prefs, check the console ...");
console.log("The problem is caused by 2 or more of these prefs:");
console.log('The problem is caused by 2 or more of these prefs:');
for(constoPrefofaDbg)console.log(oPref.name);
}
@ -201,13 +194,17 @@
constaBAK=getMyList(aPREFS);
//console.log(aBAK.length, "user-set prefs from our list detected and their values stored.");
constsMsg="all detected prefs reset.\n\n"+
"!! KEEP THIS PROMPT OPEN AND TEST THE SITE IN ANOTHER TAB !!\n\n"+
"IF the problem still exists, this script can't help you - click Cancel to re-apply your values and exit.\n\n"+
"Click OK if your problem is fixed.";
focus();
myreset(aBAK);
if(!confirm("all detected prefs reset.\n\n!! KEEP THIS PROMPT OPEN AND TEST THE SITE IN ANOTHER TAB !!\n\nIF the problem still exists, this script can't help you - click cancel to re-apply your values and exit.\n\nClick OK if your problem is fixed.")){
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.