User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Logging on to banking site (https://www.halifax-online.co.uk/personal/logon/login.jsp) second level prompt has drop downs which are now widely spaced.

Actual results:

Drop down list is widely spaced

Expected results:

Drop down lists should be narrow spaced. This is a direct result of installing FF 68 - I had experienced the problem on another computer so checked by using the banking site before installing FF 68 - correct display of narrowly spaced dropdown, installed FF 68 and re-checked and banking site had wide spaced drop-down.

I believe this is a regression of a previous bug/fix but cannot find it.

Previous Bug was Bug 1437449.

Actual results:

It looks like:
a

b

c

d

Expected results:

It should look like
a
b
c

See https://imgur.com/pSpzxiU for what it now looks like on FF 68 (and did on FF 58),
and https://imgur.com/mwYNMJJ is what it looks like on Chrome (and what it should look like).

Websites involved are part of the second level bank logon checks so I cannot provide a link to the website.

Hi,

I was not able to reproduce the issue on Firefox Release 68.0 and on Nightly 70.0a1 (2019-07-19). Please, check if the issue is still reproducible on Nightly build on your end, here is the link for the download https://www.mozilla.org/es-AR/firefox/nightly/all/

Thanks!

Bug definitely exists on FF 68 - unfortunately I cannot send you a link to the banking site to check as you'd need to be registered with Halifax bank. It also happens on another banking site (Smile).

Can I install the Nightly in parallel with having release 68 ? I do not want to mess with my normal Firefox.

You can actually see the bug in the drop down below "Request information from 'other'".

The dropdown is widely spaced unlike in Chrome (it doesn't look too bad here but there are not many options to choose from, unlike the banking site).

FF 68 screenshot is at https://imgur.com/8wTlByJ
Chrome screenshot is at https://imgur.com/WihnG1h

Just updated to FF 68.0.1, bug still present.

Hi Leam,

I was able to reproduce the bug on Windows 10 on the following versions:

release 68.0.1 (64-bit), nightly 70.0a1 (2019-08-05) (64-bit) and Beta 69.0b10 (64-bit).

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

BTW, steps:

1. forgot pwd
2. close the pop up
3. use the dropdown lists from there

The priority flag is not set for this bug.
:mats, could you have a look please?

For more information, please visit auto_nag documentation.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Emilio, it looks like bug 1375476 affected this by changing the font used in some way, even for dropdowns that don't explicitly style the <option> elements at all; is that expected?

Not really, kinda, maybe?

Looks like the page in comment 0 styles the <select> with font-family: "agendaNormal", arial, sans-serif. We don't override the font-family of options in the UA sheet, so it also styles the options... I guess that font isn't really available so we fall back to arial on the parent process.

But it seems the key is they also use line-height: 30px; on the select. So a test-case for this could be:

data:text/html,<select style="font-family: agendaNormal, arial, sans-serif; line-height: 30px; -moz-appearance: none"><option>Foo</option><option>Bar</option></select>

But that can't be it because of this rule, and it doesn't repro on Linux even with the custom styling enabled.

Jonathan, does something like the above reproduce the issue for you?

Err, sorry...

Here's the difference I see between Fx66 and Nightly, both for the styled <select> example from comment 12 and an unstyled ("native") <select>. The Nightly version does appear to have the options somewhat more widely spaced, but I think that's just a result of it using a larger font.

AFAICS the change here occurs because prior to bug 1375476, the <option>s in the dropdown menu always used the menu font, which is somewhat smaller than the font used for the <select> itself (-moz-list). But after that change, the <option>s now inherit the <select>'s font, and so they've become larger/wider-spaced. It's not clear to me that was a desirable change...

One other observation: since the bug 1375476, the <options> in the drop-down menu are inheriting their font size from the <select>, but they're not inheriting the family or style. Was that the expected behavior?

That is not expected, and not what I see.

I see italic options in data:text/html,<select style="font-family: agendaNormal, arial, sans-serif; line-height: 30px; font-style: italic;-moz-appearance: none"><option>Foo</option><option>Bar</option></select> on Linux (with the pref on).

Do you see that too? I can try to poke at what's going on otherwise when I'm on a Windows machine.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #16)

That is not expected, and not what I see.

I see italic options in data:text/html,<select style="font-family: agendaNormal, arial, sans-serif; line-height: 30px; font-style: italic;-moz-appearance: none"><option>Foo</option><option>Bar</option></select> on Linux (with the pref on).

Do you see that too? I can try to poke at what's going on otherwise when I'm on a Windows machine.

On Windows, the options in the dropdown do not show as italic for me (although the dom.forms.select.customstyling pref is true). This holds regardless of whether -moz-appearance:none is present.

On macOS, the options do get the italic style as expected. So this seems to be specifically a Windows issue.

The font issue looks resolved with bug 1590644. I'm not sure if the other issue is particularly actionable. Note that the diagnostic in comment 14 is not quite right, as it can be seen in that bug that we do override the font shorthand.

What we're starting to inherit is the font size though, and we're inheriting the font-size that the author provided in the CSS. So this looks like it's working as expected with bug 1590644 fixed.

We could try to preserve the previous behavior of using a 14px rather than 16px font-size for the default font-size, but that seems wrong/sketchy to me.

WDYT Jonathan?

The font size is very large on select options in https://onedrive.live.com/download?cid=F96BA52A2AF70D03&resid=F96BA52A2AF70D03%211505&authkey=AOzlllt0zhNgHWo.

Screenshot https://1drv.ms/u/s!AgMN9yoqpWv5i2JA5chBXPFzwVwK

(In reply to blinky from comment #19)

The font size is very large on select options in https://onedrive.live.com/download?cid=F96BA52A2AF70D03&resid=F96BA52A2AF70D03%211505&authkey=AOzlllt0zhNgHWo.

Screenshot https://1drv.ms/u/s!AgMN9yoqpWv5i2JA5chBXPFzwVwK

That website has:

#dist-option option {
    font-family: EenaduU;
    font-size: 26px !important;
    color: #222;
}

So that's what we're rendering, afaics.