I do not understand this at all, please forgive me! Also: My first Post here. No, I did not read the rules...so please forgive me if this is a rule 3 or 4 violation.
But: Let us take a look at a popular resolution:
1080p. 1920 times 1080 pixels. Full-HD. Aspect ratio: 1.7777... to 1.0 | ( . is the decimal point. Some countries use the , as decimal point!).

Now...let us search for displays (Just skip to the next paragraph):
Biggest one: bliblablub standing at 60'' (inches? ...whatever kind of stupid unit that is supposed to be...)...
Smallest one: WhateverTM Portable Monitor standing at 14" ...
(Just a quick search...could possibly find bigger or smaller ones...)...

Now...screw all that. I have a:
2560 time 1080 pixels screen. Aspect ratio ~2.3333... to 1.0 |
If I have a new Profile (Firefox Release ~86)...
Then:
layout.css.devPixelsPerPx = -1 (equals 1.25 on my PC, changing that to 20 was fun! :D ).
layout.css.aspect-ratio.enabled = false
layout.css.dpi = -1 (equals ... what does this even do?).
layout.css.width-and-height-map-to-aspect-ratio.enabled = true (How do you even know my aspect ratio? You would need my resolution for that...assuming square pixels that is...)

Are there any settings I miss or so?

I do not understand at all how one could determine / calculate the vertical space needed (for [Tool]bars)...at any given:
A) aspect ratio
B) Resolution
C) Physical screen size

EVEN IF I tell you all those 3 things...
If I hook up my Surface Pro 2 to an other Display Device...(Say an super ultra wide Display...you know...SuperDuperUltrawide 32:9 curved ones...with a resolution height of 1440)...
UI-Density would need to change again.

Best approach I can think off would be: Base everything on a minimum Font Size for everything that has a font.
Lets say my URL-Bar has a font size of 11. (or X pixels).
All other buttons on the left or the right of my URL-Bar therefor do not need to be bigger than 11 (or X) pixels.
Now if I could define X on my own free will...
And add the constant Y for "padding" so it does not look all packed together...
Y could be derived from X, e.g.: The padding could be the "n square root of X" for "n" being a positive value...
Just do not attempt to use n=<0.01041392685158230(00)...
Explanation: 0.01041392685158230 * RooT of 11 is 9.999999999e+99.
Else it breaks my calculator...maybe I need a new one?

Well...hope it is helpful in any way at all...
Else feel free to delete! :P
Many Greetings,
AZU

@Backseat-Driver If you read this:
Look at the reddit chat I send you! :)

PS: Other Data: OS: Windoof 8.1 updated to the max a poor peasant can do...
(Yeah yeah...I know...I should update...but I hate the new scaling in Windoof 10...)...
Any other questions?

It is like trying to solve a:

https://de.wikipedia.org/wiki/Unendlicher_Abstieg

"Firefox Bug (bugzilla) Nr. 1698244" and ('https://phabricator.services.mozilla.com/D108463') "$D108463 (or Bug 1695171)" can not be solved.

At least I do not see a single way to solve that #matrix# ...

Maybe my knowledge is just limited?
I could be wrong!
No matter what horizontal height or width you take...
If:
A = Horizontal...
B = Vertical...
...
(A|B) is a "certain horizontal / vertical resolution" ...
You can write it in another BASE than "Decimal" (BASE 10) or "Hexadezimal" (BASE 16)...
or BASE X.?... (?) .... ? {Might need to correct that one... ]]) . ! .
The only number I can think of to be fool-proof of that equation is:

A) PI
B) The second root of "2"

Whatever...enjoy a drink and relax, lol! :D ;) :)

(In reply to Dão Gottwald [::dao] from comment #1)

If we keep compact mode, there's room for a compromise that could satisfy both UX's vision and needs of users with small screens: Consume more space in normal mode but automatically enable compact mode on small screens / in small windows. However, depending on where exactly we'd draw the line, we might still want to look into making normal mode a bit more compact.

As a user with 1600 pixels of height, I still use and appreciate compact mode to conserve vertical space and see more content at a time. It would be a shame if the capability is there but only enable-able with a smaller window.

You are trying to solve a problem which has no answer if you do not know:
A) The physical size of a Users Screen
B) The personal preference of the Font-Size of a User (Like: How close does the User sit in front of his screen and how good is his Eyesight? Does he currently wear his glasses or contact lenses? Is he aware he can change Font-size?)
C) For small screens: The size of the Users Fingers (The amount of screen which is covered by their average fingertip)
Just:
How?
Sorry for all my rambling, but this should be a slider-option...

(In reply to Dão Gottwald [::dao] from comment #1)

If we keep compact mode, there's room for a compromise that could satisfy both UX's vision and needs of users with small screens: Consume more space in normal mode but automatically enable compact mode on small screens / in small windows. However, depending on where exactly we'd draw the line, we might still want to look into making normal mode a bit more compact.

Can't the user choose for himself? What about people using in big screen but still want to maximize the vertical space for content instead of chrome?