Fonts in chrome are larger in 102-based alphas for Mac

Here's a side-by-side comparison of 11.5.2 and 12.0a3 for MacOS:

Note how the text in the chrome is all larger, which has the domino effect of:

1. Making the chrome itself taller
2. Decreasing the available canvas area for content
3. Triggering letterboxing unexpectedly
4. Thereby causing the whole browser to open at a smaller default size than usual on MacBooks: 12-0-a3-default-window-size-macbook

That last point could arguably be spun off into a separate issue to improve the responsiveness of the layout on netbooks too.

changed milestone to %Tor Browser 12.0

added Backlog Bug Q4 UX FF102-esr labels

added Fonts label

added MacOS label

I have no idea if this is a platform specific issue, I just don't have access to anything other than MacOS to test. So please feel free to remove the label and amend the title if it's platform agnostic.

Also, I checked Firefox ESR 102.3.0 at @richard's direction and I regret to inform everyone that Firefox's chrome is the same size as stable's.

may be related to the system-ui patches (which affects chrome font, maybe sizes) @pierov except that on mac we said to use -apple-system - but not all "widgets" on mac were using that

Yes, I've set a fixed size, too.

We can set a size depending on the OS, if needed.

Changes on chrome aren't very good, but I think we don't have a way to know whether we're dealing with content or with chrome.

Also, it doesn't make sense for chrome to ask for RFP, FWIW.

Do we know which item causes this? And by that, I mean the items under system and widget fonts at https://arkenfox.github.io/TZP/tzp.html#fonts (yup, the proper solution is to exempt chrome)

---

it doesn't make sense for chrome to ask for RFP, FWIW

FWIW: Eventually it won't 1450398 as RFP would take principals into account, IIUIC 1635603.

In the past some things have been exempted on a case by case basis, e.g. pdfs used to (because at the time you couldn't exfil anything from them), not sure if it was the whole RFP or just the devicePixelRatio spoof (which caused blurring on HiDPI) but broke when pdfjs was moved from a system addon to builtin. And I remember prefers-color getting some exemptions as well for chrome theming. I guess it depends on whether you can easily get the origin or principal

---

When upstream is done in 1787790 we should check to see if chrome can be exempted

When LookAndFeel::GetFont is called by nsLayoutUtils::ComputeSystemFont, we have a document, so maybe we could use aDocument->IsInChromeDocShell().

That function is called also in GetSystemUIFontFamilies (which resolves system-ui; not sure chrome needs this font, since it can be indeed disabled with a pref).

Finally, it's called in nsNativeThemeGTK::GetMinimumWidgetSize, which has a few parameters. The first one gives a way to get the document.

I could try to create a second version of the patch.

Letterboxing issue is possibly related to #40081 (closed)

assigned to @pierov

removed Backlog label

added Doing label

@duncan could you please try https://people.torproject.org/~pierov/tmp/TorBrowser-testbuild-osx64_en-US-41356.dmg?

I'm not sure what you did, but this has fixed all the issues above as far as I can tell :)

That is a good and a bad news at the same time .

Thanks for testing, though!

Oh dear

what's the bad news? don't leave me hanging bro

The bad news is that I have to see if I can find a way to get the document with some global method, or make the patch even uglier (by adding an additional bool aRFP parameter in a few places).

lol .. "looks and feels" about elegant coding On a more serious note, do we need some engineering changes upstream? Would love to see 1787790 resolved and backported (and AFAIConcerned getComputedStyles can report the wrong properties all it likes - edit: for nonRFP)

do we need some engineering changes upstream?

The new patch is !394 (merged) (well, to be added to the previous one).

It isn't super bad after all, I thought it would be much worse, but maybe I was modifying the wrong part in the first attempt.

I'd go for a review here, to be sure it's sensed, and then go through phabricator, as a gentle push to have it considered.

marked this issue as related to #41116 (closed)

mentioned in merge request !394 (merged)

closed

removed Doing label

mentioned in issue #40789