Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changelog: v94 #1277

Closed
Thorin-Oakenpants opened this issue Nov 23, 2021 · 13 comments
Closed

changelog: v94 #1277

Thorin-Oakenpants opened this issue Nov 23, 2021 · 13 comments

Comments

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Nov 23, 2021

changelog: v94

  • date: 23-November-2021
  • foreword: These are all the changes since the last changelog (v92,93).

FF94 release notes
FF94 for developers
FF94 security advisories


CHANGELOG: [all changes]

  • links to bugzilla tickets and default pref changes in Firefox are in our ToDo: diffs FF93-FF94 issue
  • for all the rest see the full list of pref changes below

⭐ your friendly reminder to run prefsCleaner

  • ESR78 is EOL, it is no more, bereft of life, passed on, snuffed it, and bitten the dust
  • v94 still contains the prefs deprecated during the ESR78 lifecycle in 9999
  • v94 still contains the prefs previously active but removed from arkenfox during the ESR78 lifecycle in 6050
  • they will not be there next release so run prefsCleaner while you can

  • new in user.js v94
   // user_pref("browser.warnOnQuitShortcut", false); // [FF94+]
   // user_pref("layout.css.font-visibility.private", 1);
   // user_pref("layout.css.font-visibility.resistFingerprinting", 1);
   // user_pref("layout.css.font-visibility.standard", 1);
   // user_pref("layout.css.font-visibility.trackingprotection", 1);
   // user_pref("privacy.clearsitedata.cache.enabled", true);
   // user_pref("extensions.systemAddon.update.enabled", false); // [FF62+]
   // user_pref("extensions.systemAddon.update.url", ""); // [FF44+]
   // user_pref("privacy.clearOnShutdown.siteSettings", false);
   // user_pref("privacy.cpd.passwords", false);
   // user_pref("privacy.cpd.siteSettings", false);
user_pref("privacy.clearOnShutdown.cookies", false); // was true
user_pref("privacy.cpd.cookies", false); // was true
user_pref("network.cookie.lifetimePolicy", 2); // was inactive

STATS

 STATS v94: up to and including section 4500, minus the parrots
 =========
    total: 235
 inactive:  55
           ---
   active: 180
  default:  21 (at least)
      n/a:   2 (of the three prefs in 0204, only one will apply)
           ---
  flipped: 157 (at most)
@Thorin-Oakenpants
Copy link
Contributor Author

ALL HAIL PANTS

Collect the set

who needs fucking peacocks when you can have a nutterbutter
allhail

@ginick
Copy link

ginick commented Nov 23, 2021

Thank you

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Nov 24, 2021

also, we passed 4000 stars, so that'll be another beer 🍺 ... we'll catch that @bagder 's curl repo yet

That's over thirteen (I need to learn math) fourteen Spartas + Gerard Buttler

4000

@rusty-snake
Copy link
Contributor

@Thorin-Oakenpants do you like to include this in the README.md?

Stargazers over time

https://starchart.cc/arkenfox/user.js

@Marc05
Copy link

Marc05 commented Nov 24, 2021

I feel like the enable session restore recipe should include user_pref("network.cookie.lifetimePolicy", 0); at least as an optional for users that still manage cookies with CAD.

My reason for using CAD is that it supports containers. I can allow cookies to be kept for just one permanent container instead of allowing all permanent containers to keep that site's cookies when using the native site exceptions. If I'm wrong on how that works, please correct me.

@rusty-snake
Copy link
Contributor

enable session restore recipe:

  • SR actually works with places.history.enabled=false
  • Cookies are restored even with browser.sessionstore.privacy_level=2 (note that I don't use network.cookie.lifetimePolicy=2).
  • browser.sessionstore.privacy_level=0 restores formdata even with privacy.clearOnShutdown.formdata=true.

user_pref("privacy.window.maxInnerWidth", 1600);
user_pref("privacy.window.maxInnerHeight", 900);

Firefox is now higher than with the default of 1000 LOL.

@Thorin-Oakenpants
Copy link
Contributor Author

Firefox is now higher than with the default of 1000 LOL

Well, actually, the height is lower. But the width being higher is the whole point.

@rusty-snake
Copy link
Contributor

For me new windows a now higher than before. Anyway my WM maximizes firefox now automatical ly because it is close to maximum, but if you un-maximized it, you see it.

@Thorin-Oakenpants
Copy link
Contributor Author

ok ... not sure if I can replicate. I need some numbers. What is your available screen res and system scaling. What is your inner vs outer, just un-maximize, toggle RFP and use TZP) - that is I need to know what the chrome is using)

So you open at A x B, WM maximizes FF, you click restore, but it doesn't restore to A x B?

@Thorin-Oakenpants
Copy link
Contributor Author

Also, I know there are "bugs" with new win, including tiling managers (even at 1000 x 1000 max) - and IDK if anything can be done about external programs altering new win after the fact - and that is what letterboxing fixes. On the bright side, you're opening maximized and therefore getting as much real estate as possible on smaller screens (under 1600x900) - which was the plan

@rusty-snake
Copy link
Contributor

Seems to be some mess between Firefox/RFP and the WM.

maxInner: 1600x900 RFP: on

1600x900_RFP-fs8

flip RFP of and reload

1900x900_noRFP-fs8

maxInner: 1000x1000 RFP: on

1000x1000_RFP-fs8

maxInner: 1600x900 RFP: on letterboxing: false

1600x900_RFP_noletterboxing-fs8

@Thorin-Oakenpants
Copy link
Contributor Author

🔸 maxInner: 1600x900 RFP: on

  • looks perfectly good to me, despite the tiling manager, letterboxing has protected you

🔸 flip RFP of and reload

  • you have 1920 x 1080 available (for all intents and purposes: i.e it does not matter if you are twice as large but at 200% system scaling)
  • your chrome takes up 117 x 190 which is not right: LB is still on
    • by comparison: my chrome takes up 12 x 126
    • outer vs inner: your outer is off screen: says it is 1090 by your screen is only 1080 (that will be a side effect of the previous test when the tiling manager kicked in - xulstore.json in yur profile remembers last window positions and sizes) - we can ignore this as a symptom and not a problem IMO
  • lets assume your chrome uses e.g. 10'ish x 120'ish
  • this would leave 1800'ish x 950'ish for inner to work with, and 1600 x 900 fits in there - as per your previous test

🔸 maxInner: 1000x1000 RFP: on

  • as expected, tiling manager doesn't resize - you have 1800'ish x 950'ish for inner to work with, and 1000 x 900 fits in there

🔸 maxInner: 1600x900 RFP: on letterboxing: false

  • this doesn't tell me anything: I already got the values in RFP off (but letterboxing was on and that obscures the chrome sizes but we don;t really need them, we can guestimate)

So it's your tiling manager kicking in, but you still conform to the max sizes, get more real-estate, and letterboxing protects you. The restore bit is a bit confusing for me. Is it maximizing or resizing to fit the screen - because the 1090 height is weird. Anyway, it's all a bit moot when it's an external program

You can change the max values if you want if you don't like being "maximized", or can you tell the tiling manager to ignore firefox? IDK - up to you

@rusty-snake
Copy link
Contributor

Actually it's a compositing WM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants