You could also make this a ratio of tabstrip height to window height. E.g. 0.04:1.
Personally and very subjectively, I didn't find this cut-off useful fwiw. I had to bump my resolution to a crazy size to get uidensity to *not* be compact.

Is the compact mode also dynamic based on window size, or just screen size?
That may be scope creep, but if we are doing in in browser.js (i.e. per window) I would think it should be window-size dependant and so you'd want to watch for resize events as well. Maybe that's a different bug and discussion though.

Do we really want the tabstrip height as ratio of screen width? I suspect we dont need to look at the width at all actually - as compact mode doesn't really help much with narrow windows. If we do, we should compare against a reference width not height.

Again, in my head this is a ratio, so H / screen.width = 0.04444 or whatever, so we express the threshold as when the tabstrip is taking up more than its fair share of the vertical space, i.e. it exceeds some proportion of the window height. More than 4% means we engage compact mode. But either works.

I think this should be an absolute number, because it's absolute pixels that constrain us in terms of being able to fit buttons on the toolbar etc. This would be in line with our pre-existing logic here (which I think we should be able to simplify based on your work here): https://searchfox.org/firefox-main/rev/e28b34ab33dbf49364999070168cbb7e11e8e5bd/browser/themes/shared/toolbarbuttons.css#7-33

@dao Are you suggesting we use separate prefs for height and width?

We've discussed this separately. The toolbar button logic I linked to above is somewhat orthogonal to this patch, although there's likely room for consolidation that would be good to look into in a follow-up. For now we can carry on with this current approach of having a relative threshold.