Affected versions

• 76.0, 77.a1(‏(2020-05-04

Affected platforms

• macOS 10.15.3

Steps to reproduce

1. Launch Firefox;
2. Open at least 2x tabs;
3. Click on the close button for browser;
4. Hover over the Cancel button

Expected result

• text contained in buttons;

Actual result

• font out of bounds for the no character

Regression range

• will check if one and provide asap;

Additional notes

• attached screenshot with the issue.

Hover over the Cancel button

To clarify: does this button-hovering seem to trigger a layout-change (which then results in the broken rendering)?

(If so, this seems like it might be a result of the XUL grid removals & weirdness around intrinsic sizing when we have modern CSS grid intermixed with XUL stuff -- e.g. bug 1593060 & bug 1610597)

(of course, this could conceivably be de-XUL-grid fallout regardless of whether the hovering is involved. A regression range would help a lot with identifying what's going wrong!)

The regression window would be very helpful here - even a very rudimentary one in terms of whether you can repro with 74 or 68 esr.

Confirmed issue with:

• macOS 10.15.3: 74.0.1, 68.8.0esr, 45.3.0esr (older builds don't want to start up).
• macOS 10.12: 77.0b1
  Looking at it, it is not a regression.

As for the hover part, it was meant to be something that helps with identifying the affected area faster.
Step 4, is not mandatory for it to notice the issue; sorry for the confusion on that part.

I'm not sure this is a regression, nor that it's particularly unexpected. The Arabic label "ألغِ" for the Cancel button has a character, the Kasra diacritic, that is placed below the descender of the Ghain letter, which (in many fonts, including Geeza Pro which I think is what's being used here) puts it below the normal "descent" metric of the font. So if text is set with typical line spacing, this will tend to project beyond the normal bounds of the line. (Note that these diacritics are rarely written in modern Arabic. In fully-voweled text such as the Qur'an, it would be usual to increase line spacing a bit to accommodate the diacritics.)

The glyph projecting beyond the nominal bounds of the line can clearly be seen with a testcase like:

data:text/html;charset=utf-8,<span style="font-family:geeza pro;font-size:64px;background:silver">%D8%A3%D9%84%D8%BA%D9%90</span>

Note that it's equally possible for diacritics to end up projecting above the normal ascent of the line of text, as in:

data:text/html;charset=utf-8,<span style="font-family:geeza pro;font-size:64px;background:silver">%D8%A7%D9%8F%D8%B1%D8%AF%D9%8F%D9%88

Which -- if it happened to occur in the button label -- would result in a similar issue at the top.

To avoid this, we could presumably add some top- and bottom-padding; something like 0.2em would probably be sufficient to accommodate anything that's likely to occur. But the downside would be that most buttons, with labels that don't happen to include particularly high or low diacritics, will look like they're excessively tall for their content.

FWIW, I notice that the macOS Arabic localization seems to use a different form of the word for Cancel, "إلغاء", which does not have the low diacritic we see in "ألغِ", and therefore fits better into "normal-sized" buttons.

One other observation: "إلغاء" also seems to be the usual term in Microsoft's Arabic localization, according to https://www.microsoft.com/en-us/language/Search?&searchTerm=Cancel&langID=39&Source=true&productid=0. (Sometimes expanded to "إلغاء الأمر".)

This makes me wonder whether there's a compelling reason the Firefox localization is using the form "ألغِ", when both Apple and MS products, at least, have gone for "إلغاء". That would be a question for the AR localizers to consider...

Moving this to the Localizations product, as I don't think there's really a Core Layout bug here.

I don't know whether adjusting the button size just for the Arabic localization is even a possibility. Increasing it across the board (for all languages) by a global change to the front-end styling would probably be unwelcome in most cases, as many buttons would look excessively padded.

Alternatively, adjusting the translation to avoid the low diacritic (and, incidentally, to follow macOS and Windows platform conventions more closely) might be worth considering.

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Spam traps are boring so I'm just disabling comments at this point.