Get rid of @supports "layout.css.osx-font-smoothing.enabled" pref

[MrOtherGuy]

We have used the enabled state of "layout.css.osx-font-smoothing.enabled" pref to detect if the system is macos, and it has been possible to use it to set window controls to the left side on other platforms too. But now that @media (-moz-platform: macos) is a thing, we should just use that and similarly @media (-moz-gtk-csd-reversed-placement)

However, this is not a simple change since it affects at least the following styles:

• combined_tabs_and_main_toolbars.css
• hide_tabs_toolbar_w_alltabs_button.css
• multi-row_oneliner_combo_patch.css
• navbar_tabs_oneliner.css
• navbar_tabs_oneliner_menu_buttons_on_right.css
• navbar_tabs_oneliner_tabs_on_left.css
• navbar_tabs_responsive_oneliner.css
• overlay_menubar.css
• tabs_on_bottom.css
• window_control_placeholder_support.css

The desired behavior is to have all of these work on all platforms by default, and to still have a pref that can be used to set left-side window-controls on platform that don't normally have them (i.e. Windows).

I propose we invent a new pref for this userchrome.force-window-controls-on-left.enabled for clarity - but it's still bunch of work to make the above styles to work correctly.

Note, some of the above styles depend on the behavior of window_control_placeholder_support.css while others do not. Additionally, it would be great if we could just put all this logic into the placeholder_support style, but I don't think that's possible since the placement depends of what the "main" style (e.g. hide_tabs_toolbar.css) is actually doing. As such it's probably best to have the support sheet only create the placeholder space and have the style-specific changes be in the "main" style.

[MrOtherGuy]

Patch 95fbda2 adds preliminary fixes for few of the affected styles. I'm reasonably sure nothing broke too much, but I would really like someone with macOS confirm that things work alright.

[COOLak]

Doesn't work at all, here's a screenshoot from MacOS with this css. The only change is that the system icons (close, minimize, maximize) are weirdly placed on top of the tabs, which themselves still sit on top.

[COOLak]

Here's my fork that works best for me both on Windows and MacOS, but on the latter, the position of the aforementioned buttons is still weird. Plus there's an extra black bar on top. But at least it works, and the tabs are not huge.

Screenshot on MacOS with my fork:

[MrOtherGuy]

I'm not sure what styles you are trying to use (this change affected several), but it seems to me that at the very least you are completely missing the window_control_placeholder_support.css which is what creates space for the window controls in other toolbars.

I'd say the black bar in your second image is explained by the fact that you included tabs_on_bottom_menubar_on_top_patch.css which can't possibly work on macOS since menubar doesn't even exist there - so that style creates space for it (the black bar) but nothing can be shown there.

[COOLak]

Would you be so kind as to propose a solution for MacOS in which I could retain the same size of tabs as in my fork (which is by the way just your old version of the tabs_on_bottom.css adjusted for newer Firefox versions) but so that the MacOS window buttons are placed in a normal way? And also I just noticed that I'm missing a "new tab" (+) button now. I've been using this fork of mine on Windows for a long time, and it's just perfect for me, and I wish I could achieve the same on MacOS. Of course, I'm not meaning having the menu bar that doesn't exist here, as you correctly pointed out. It's just, without it, window buttons are placed on top of the browser navigational buttons (back and forward).

[MrOtherGuy]

You should be able to do that using just tabs_on_bottom.css with window_control_placeholder_support.css - so this set and then to change tab vertical size just add this to the end:

:root{
  --tab-min-height: 28px !important;
}

That is all assuming the that MacOS rules are working as intended of course. But on Windows and on Linux at least these should work fine.

[COOLak]

Oh well, that's near perfect! Thank you very much!

The only thing is, as shown on the screenshot below, the window buttons aren't exactly in the upper left corner, but a bit below that. Would appreciate tips on improving this new layout, but even right now, it's certainly the best variant out of all my miserable attempts. Thank you Guru.

[MrOtherGuy]

I'd like to understand why those buttons get moved so far down... I can't find a plausible reason for it for Firefox source files either. But I cannot debug it further since I have no access to any mac system.

Nonetheless, you should be able to fix it for yourself by adjusting the top property on tabs_on_bottom line 18 - make it something negative like -12px; to move it upwards.

[COOLak]

@MrOtherGuy, thank you once again, -17px did the trick for me. Another issue is that the nav buttons (back, forward, refresh) must be on the very left, and for some reason they've been moved to the right by a solid margin as you can see from the same screenshot. I tried moving them, but they don't want to go leftier than they are. And including an expandable space to the right of them only makes the rightier items smaller, while having no effect on the nav buttons. They like stuck there and won't go any leftier.

For comparison, here is a piece of screenshot from my Windows PC:

[MrOtherGuy]

Those spaces are expected, they there to drag the window around - but they are only there when the window is not maximized. This is normal Firefox behavior, well if menubar is enabled then these drag spaces are not shown, but that tabs_on_bottom_menubar_on_top_patch makes that work. We just make them appear in nav-bar instead of tabs toolbar because now tabs are not the topmost toolbar.

But if you do want to change the width of those spaces then you can do that by editing the variables at lines 16 and 17 of window_control_placeholder_support

[COOLak]

It's so much better now when I set those to 0px, thank you!

By the way, those spaces were still there with the window maximized.

Now I wish we could move the back and forward buttons to the very left and just below the window buttons. That would be perfect.

[MrOtherGuy]

Now I wish we could move the back and forward buttons to the very left and just below the window buttons.

If you want to do somethingvlike that then you could just set the value on line 38 to 0px - right here

On that note, looking at the code it does kinda seem like there might be a bug in that on macos the spacer is shown even in maximized windows like you said.

[MrOtherGuy]

Hmm, maybe my previous assessment is not actually correct. Searching for .titlebar-spacer in searchfox would seem to indicate that the spacers are only hidden in Windows and Linux when window is maximized. But on MacOS they are always shown so the current behavior of window_control_placeholder_support might actually be correct.

Of course, you can always change it like mentioned above, but the default behavior should probably be to show the spacers always on macos.