Redjard

With the update there was an overhaul of what combinators can do.
I had the problem that my oil cracking would flicker, turning on for a split second then back off again, hovering right around the set threshold. (Probably worsened by me not switching a pump anymore like what used to be the norm.)

The old method would have been an SR latch, which enables at a higher set point and disables again at a lower reset point. This used to take 3 combinators.

~~I figured it should be possible to do better now, but could not come up with a way to cram an sr latch into a single combinator, since it can only be either on or off at one time. I think it takes two combinators to build an sr latch now.~~
A single-combinator SR latch is in the comments.

Instead I came up with another way to "debounce" my cracking.

Here shown is the combinator sending the signal to enable cracking (the recipe icon of light oil cracking) while the actual activation signal, light oil above 20k, is off.

The signal was on for a moment, then after the cracking started up the oil level immediately dropped below 20k again. But now the second condition, T between 0 and 10s, is active. While the combinator is active, it is sending out 1 plus the old count to T, counting it up once per frame. It remains active while the condition is active or while T is counting up but has not yet reached 10s (at 60 ticks per second). This ensures that every time the cracking runs, it runs for at least 10 seconds.
After these 10+ seconds, the level should take a while before rising above the threshold again.

For me, this successfully made the row of chem plants turn on in one smooth go.

3x the previous all time high just shy of 35k in August 2020 when 1.0 released - on a Friday during the pandemic.

I have been playing around with pwa-like experiences, and as part of that I tested "kiosk mode".

For those who don't know, you can start a "kiosk window" with the command firefox -kiosk --new-window <url>, which will open that url in fullscreen without a titlebar, right click menu, any overlays like the link preview or loading text, ...
I cancelled the fullscreen flag of my window, and had a resizable fully functional website in a frameless window.

Which was great and all, until I realized that in my running profile now every newly opened window is also in kiosk mode, and right click was globally disabled. My running firefox instance has been infected by the kiosk disease.

Anyway, it's not a large issue, I can just restart my infected instance. But I hate restarting my browser, it usually runs for multiple months.

My question is, is it possible to leave kiosk mode without restarting firefox?

I updated my firefox from 119.0.1 to 121.0 two days ago, and have noticed a for my usage quite significant change:
When I have a page, say a search engine query or a gallery of links on a page, and I open one then go back, previously I got the cached version. Within reason of the cache size I could go back a few pages even days later and critically see them as they where, just like I would expect for a tab I have open.

I use this behavior to work through essentially todo lists, so now that the lists get reloaded every time I visit them, this combines with server side caching to make the list jump around quite annoyingly.
My expected behavior would be the cached back history being served when available, except when I manually hit F5.

Was this change intentional? Is there any way to get the old behavior back?

Edit:
It seems to be a bug and only happen on some profiles, potentially dependent on some metric related to heavy use, like number of open tabs and windows.
Edit:
It seems to be related to uBlock Origin.
Edit:
It is definitely an issue within ubo, I will add a link to the issue there when I create it.
Edit:
It seems to be caused by the "AdGuard Tracking Protection" filter list within ubo.
Edit: issues:
ubo filters: https://github.com/uBlockOrigin/uAssets/issues/21841
AdguardFilters: https://github.com/AdguardTeam/AdguardFilters/issues/170172
Edit:
It was fixed a few minutes ago, the changes should percolate through to ubo soon™. Thx Yuki2718.

For those who don't know,
The Multi Key is a key you can set on linux, with which you can type an insane amount of unicode characters. It is commonly bound to scroll lock, I will represent it with ↓ here.

A few examples of shortcuts would be
↓TM → ™
↓|v → ↓ (the character I am using here)
↓+- → ±
↓co → ǒ

Now, most of those work just fine in Firefox, but weirdly there are some that don't. For example ↓PP produces ¶ just fine, but ↓RR doesn't type ℝ. for ↓RR the Multi Key input stops, like it does once no more valid sequences are left that match the current input. ↓CC also doesn't type ℂ, but it doesn't stop but continue on as if there was a different sequence starting with CC. I don't see anything special about the sequences that don't work compared to the majority that do.

After some trial an error, I think what is happening is that firefox does read my .XCompose, but the line include "%L", that is supposed to load the default Compose file located in /usr/share/X11/locale/en_US.UTF-8/Compose is ignored. It is not a language configuration error, as include "/usr/share/X11/locale/en_US.UTF-8/Compose" is ignored too. Entering some deliberate modifications or even removing existing sequences from the Compose file doesn't affect Firefox.
I even found some sequence ↓a_ which is supposed to yield ā but firefox has as ª (not to be confused with ᵃ the superscript a) instead.

Searching for the place Firefox' Compose is defined, I grepped for "ª" which is a pretty rare character, and hit libxul.so. I tried a bunch of other characters and found pretty much everything that has a compose sequence is found in that file.

So thus my question would be: Are Firefoxes default compose sequences statically compiled into libxul.so? And if so, why?