1769580 - firefox 100 drop downs aren't wide enough to show both digits of port number, on Netgear GS724TPv2 ProSAFE (due to its use of `text-indent: 0.01px; text-overflow: ""` on intrinsically-sized content)

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[garrykempster]

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

Steps to reproduce:

login to Netgear managed switch go to any gui page with a dropdown click the dropdown and make a selection the dropdown in the switch gui remains as the initial selection.

Actual results:

dropdown reverts to default gui selection and doesnt change to the selection.

Expected results:

dropdown selection should have been made and reflected in the switch gui

Comment 1

[Daniel Holbert [:dholbert]]

Thanks for the bug report!

We may have a hard time investigating without a live website that we can test with, unfortunately. I don't have a netgear managed switch available for testing, and I suspect I can't just find a publicly viewable page to test with.

Would you mind trying to create a standalone testcase, e.g. by viewing an affected page and doing "File | Save As..." and being sure "HTML, complete" is selected at the bottom of the save dialog (so that scripts/etc. get saved), and then see if that saved result still reproduces the bug? If it does (and if you're reasonably confident no confidential info is included in the saved file), you could zip that up and attach it here, or email it to me if you want to be cautious about potentially-confidential info being included from your switch. (dholbert at mozilla dot com)

Also: do you know if this used to work properly and only stopped working in Firefox 100 (or some other recent version-bump)? e.g. bug 1744009 comes to mind as a change to dropdowns that we shipped not too long ago, but that patch was part of Firefox 98, so it wouldn't be involved here if this broke more recently than that version.

Comment 2

[Daniel Holbert [:dholbert]]

Actually, I just remembered I have a Netgear GS108Tv2 smart switch, and it does seem to have a Web UI, which I visited for the first time to test out this bug.

RE your steps to reproduce:

go to any gui page with a dropdown
click the dropdown and make a selection
the dropdown in the switch gui remains as the initial selection.

I'm not seeing that issue. When I click a dropdown and make a selection, the dropdown shows the selection that I made, as you'd expect.

e.g. when I visit http://<switch IP Address>/base/web_main.html and click the "QoS" tab, I see:
[x] Global with a dropdown to the right that says "Global Trust Mode". If I open that menu and choose some non-default option and then close that menu by clicking elsewhere, I see my choice get reflected in the closed menu.

So: I can't reproduce yet.

Could you:
(1) Let us know the specific model of your switch (in case the issue you're hitting is specific to the WebUI on certain switches, not just NetGear in general)
(2) Test to see whether you can reproduce the issue in a brand new Firefox browser profile? That helps rule out whether one of your add-ons or pieces of internal Firefox configuration might somehow be involved. See https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles#w_manage-profiles-when-firefox-is-openfor how to do that -- essentially visit about:profiles, click "Create a new profile", click through the process, and then "launch profile in new browser". (Note, the new profile will automatically become your default, so you'll need to restore your original profile to be the default one using the appropriate button on about:profiles once you're done testing.)

Thanks!

Comment 3

[Daniel Holbert [:dholbert]]

Also:
(3) Could you provide more concrete steps-to-reproduce? e.g. if you could provide a specific dropdown on a specific page (on your switch's WebUI) that you've confrimed is broken, and that other folks are likely to be able to find on their own netgear swiches?

Comment 4

[garrykempster]

The switches in question are Netgear GS724TPv2 ProSAFE all was fine until firefox 100. If I am trying to add a static MAC address to a particular switch port under Switching/Address Table/Advanced/Static MAC Address when chosing a port i.e. 15 from the dropdown box when clicked the dropdown stays at port 1 and I have no idea if port 15 has been selected. I have just noticed it may be a numerical issue as if i select ports 1 - 9 in the dropdown menu when clicked they reflect the change, ports 11 to 24 stay at port 1 in the dropdown when clicked. When I visited the QOS settings in the gui i can make any selection in that menu and my choice is reflected in the menu. I have confirmed this on multiple installs of Firefox and still present on 100.0.1 hope this helps.

Comment 5

[Daniel Holbert [:dholbert]]

Thanks! Unfortunately I can't reproduce the issue there. (For what it's worth: in my case those, those ports -- in the Interface column -- are labeled g1 through g8 and then l1 through l4. And they all seem to be properly selectable).

But I have a theory...

Given that values 1-9 are fine and 10+ are bad, where "bad" means you just see a "1"... I wonder if the problem is just that the dropdown menu is too skinny to show the full 2-digit number, and it's just cutting off the second digit so you can't see it. So it does really have 11 or 15 or whatever, but it's just clipping off the second digit.

Does it look like that might be the problem? If you use Firefox's devtools to inspect one of the dropdown menus and give it e.g. width: 80px !important in its style (to make it wider), can you see the full value?

Regardless of whether that's the problem, it would be really helpful if you could save a copy of the affected page, and attach the saved copy here or mail it to me (dholbert at mozilla dot com), for further investigation & to help track down what might have caused the behavioral change.

Comment 6

[Ray Kraesig [:rkraesig]]

(In reply to garrykempster from comment #4)

[...] all was fine until firefox 100.

Since this is Firefox 100-specific, you might also want to try the mitigation described here, just in case:
    https://support.mozilla.org/en-US/kb/difficulties-opening-or-using-website-firefox-100

Comment 7

[garrykempster]

Hi Daniel that is indeed the case adding width: 80px allows both numbers in the dropdown to be shown so it was selecting the correct dropdown just not displaying it(In reply to Daniel Holbert [:dholbert] from comment #5)

Thanks! Unfortunately I can't reproduce the issue there. (For what it's worth: in my case those, those ports -- in the Interface column -- are labeled g1 through g8 and then l1 through l4. And they all seem to be properly selectable).

But I have a theory...

Given that values 1-9 are fine and 10+ are bad, where "bad" means you just see a "1"... I wonder if the problem is just that the dropdown menu is too skinny to show the full 2-digit number, and it's just cutting off the second digit so you can't see it. So it does really have 11 or 15 or whatever, but it's just clipping off the second digit.

Does it look like that might be the problem? If you use Firefox's devtools to inspect one of the dropdown menus and give it e.g. width: 80px !important in its style (to make it wider), can you see the full value?

Regardless of whether that's the problem, it would be really helpful if you could save a copy of the affected page, and attach the saved copy here or mail it to me (dholbert at mozilla dot com), for further investigation & to help track down what might have caused the behavioral change.

Hi Daniel that was indeed the case adding width: 80px allows both numbers in the dropdown to be shown so it was selecting the correct menu option from the dropdown list just not displaying it. As the switches are both at my business I am unable/not allowed to save and send the page.

Comment 8

[Daniel Holbert [:dholbert]]

Gotcha. I understand, though unfortunately that makes it a bit hard for us to investigate what the problem could be; but we can still make some headway with your continued cooperation!

Could you try the workaround in comment 6, and see if the bug still reproduces? (Lots of sites have scripting that produces unexpected results as a result of Firefox 100 being 3 digits; comment 6 can help us identify or rule out whether that might be part of the problem here.)

If that workaround doesn't help: could you use Firefox's devtools to capture some information about how your Netgear switch is styling these dropdown menus? I'll post a screenshot showing what in particular would be helpful to capture.

Thanks!

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screenshot from dholbert's machine showing what information would be useful to capture

Here's a screenshot showing what I'm hoping you can capture for us, to help understand what styles are applied to these dropdowns on your system (so we can have a shot at understanding and maybe reproducing this locally).

Comment 10

[garrykempster]

Attachment: Capture.JPG

I have tried changing the Firefox version number to 99 it made no difference.

Comment 11

[Daniel Holbert [:dholbert]]

Thanks! That screenshot is helpful but doesn't capture all of the relevant styles. That middle pane (the large box from my screenshot) is the part that I'm curious about, but unfortunately it's got enough content in this case that it's not all visible (note the large scrollbar).

Could you right-click inside that area (near e.g. "padding-left: 2px" etc. in your screenshot) and choose Select All, and copy/paste the selection into a comment or attachment here? (Note that this section is just styling with no actual content, so it won't include any actual data from your network etc.)

Comment 12

[garrykempster]

element {
}
.xuiInputTextDisabled, .xuiInputPasswordDisabled, .xuiTextAreaDisabled, .xuiSelectDisabled, .xuiInputTextEnabled, .xuiInputPasswordEnabled, .xuiTextAreaEnabled, .xuiSelectEnabled {
font-size: 9pt;
font-family: Arial,Verdana,Helvetica,sans-serif;
padding-left: 2px;
color: #666666;
border: 1px solid #CCCCCC;
padding-right: 2px\10;
}
select {
-moz-appearance: none;
-webkit-appearance: none;
background-image: url("../images/Expand_normal.gif");
padding: 2px 19px 2px 2px;
padding-left: 2px;
background-position: right 5px center;
background-repeat: no-repeat;
border: 1px solid #CCCCCC;
outline: #CCCCCC solid 1px;
outline-offset: -1px;
margin: 0;
text-indent: 0.01px;
height: 16pt;
text-overflow: "";
line-height: 1.6em;
}
.defright {
border-collapse: collapse;
font-family: Arial,Verdana,Helvetica,sans-serif;
font-size: 10pt;
color: #666666;
text-align: left;
white-space: nowrap;
line-height: 1;
}
.defaultFontBold, .defaultFont, table tr td {
font-size-adjust: none;
font-stretch: normal;
font-family: Arial,Verdana,Helvetica,sans-serif;
font-size: 10pt;
font-style: normal;
font-variant: normal;
font-weight: normal;
line-height: 1.6em;
color: #666666;
}
td, tr {
border-collapse: collapse;
}
table.tableStyle {
border-spacing: 0px;
border-collapse: collapse;
font-family: Arial;
font-size: 10pt;
}

Comment 13

[Daniel Holbert [:dholbert]]

Thanks! I can reproduce the issue, in a local testcase with that styling.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (based on styling from comment 12)

Comment 15

[Daniel Holbert [:dholbert]]

EXPECTED RESULTS: The select should show 16.
ACTUAL RESULTS: The select shows 1

With testcase 1, on my linux Thinkpad, I get this regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5d2b9a1b0aa75ff249f7d3087c7bd57d29a8d7ad&tochange=8720b5f8902c1ced04d063eb2b0b229b9182657c

So that would be bug 1147847, where we toggled widget.gtk.overlay-scrollbars.enabled to default to true on Nightly.

If I set that pref to false in the first-bad Nightly, I get expected-results (confirming that the pref-flip was responsible for the change in behavior in that range.)

But if I set the pref to false in current Nightly, I get ACTUAL RESULTS, so we eventually regressed even with that pref set to false. That happened with this range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=04454a753d1a0354e9ff59337d55cc3b85b148fc&tochange=bd4c36e21201ebfeb8981030330c04d8fb77cc0d
...which is bug 1762873, which changed the intrinsic sizing behavior of select elements.

On Windows, presumably this regressed from either the Windows equivalent of bug 1147847, or perhaps from bug 1762873.

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced)

Here's a reduced testcase. The crux of this is that they have this unfortunate combination of CSS declarations, on an intrinsically-sized element (the <select> dropdown):

text-indent: 0.01px;
text-overflow: "";

This, combined with the automatic width, is the site asking:

• Size this component to exactly fit its contents (the text)
• and then indent the text by 0.01px
• and if anything overflows, just clip the overflowing text (replace the overflowing character with "")

Not-too-surprisingly, the 0.01px indentation causes overflow (since this is sized-to-content) and hence clipping (per text-overflow).

This "works" in other browsers because they reject the text-overflow declaration -- Firefox is the only browser to support this text-overflow: <string> syntax, per https://caniuse.com/mdn-css_properties_text-overflow_string .

This worked in earlier versions of Firefox because we had a little bit of breathing room because we were setting aside some space for the scrollbar (and I guess the text overlapping 0.01px into that space wasn't considered to be overflowing).

Comment 17

[Daniel Holbert [:dholbert]]

On Windows 11, I get this regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3f8699724d492a8f00f7ad8d26b16c71236c311e&tochange=21553c91b278c428b4c8e861602a99fb1c1acc70

That implicates bug 1757647, which added overlay scrollbars for Windows 11 (analogous to bug 1147847), behind the pref widget.windows.overlay_scrollbars.enabled, which we renamed to widget.windows.overlay-scrollbars.enabled (hyphen instead of underscore) in bug 1761690. If I run with those prefs forced to false, I get this regression range:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=04454a753d1a0354e9ff59337d55cc3b85b148fc&tochange=bd4c36e21201ebfeb8981030330c04d8fb77cc0d

...which is the same as at the bottom of comment 15.

So:

• This was proximally regressed by the patches that enabled overlay scrollbars on various platforms (different patch/timeframe for each platform, including Win10 vs Win11 it looks like, but in/around the Firefox 100 release cycle).
• For users who pref off overlay scrollbars, this was regressed by Bug 1762873.
• ...and really it's just pretty-silly content (per comment 16), which asks for text to be truncated (in a way that only Firefox supports) and pushes it right up to the edge and then gives it a 0.01px nudge off the cliff. :-/

Given that this is in web UIs of actual physical client devices (Netgear switches), it's a bit harder to just get the web content itself fixed, so we may need some sort of hackaround /accommodation ourselves here (maybe adding some fractional pixel of breathing room, under certain conditions?)

Tentative ni=emilio for thoughts since he seems to have been the main person working on the various overlay scrollbar patches that are implicated here.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Yeah, I don't think there's a great way to fix this, the behavior we have is reasonable...

I can attach a hack, but it makes me a bit sad tbh :-/

Ironically, bug 1764768 would also fix this, because 0.01px would get truncated to 0px rather than rounded to one app unit. But I'm not super-convinced that's fully desirable, see my last comment there...

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1769580 - Add a terrible hack to avoid Netgear's <select>s from overflowing port numbers. r=dholbert

Not a fan of this, I'd rather not do this... A potential, maybe less
hacky alternative, would be to resolve text-indent by truncating rather
than rounding. That would effectively round down the 0.01px to zero.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1b641947f6a7
Add a terrible hack to avoid Netgear's <select>s from overflowing port numbers. r=dholbert

Comment 22

[Emilio Cobos Álvarez (:emilio)]

For the record this text indent thing seems like a really old hack (hasn't been needed for ages) to hide the arrow, see https://stackoverflow.com/questions/23920990/firefox-30-is-not-hiding-select-box-arrows-anymore

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9277631 [details]
Bug 1769580 - Add a terrible hack to avoid Netgear's <select>s from overflowing port numbers. r=dholbert

Beta/Release Uplift Approval Request

• User impact if declined: Some old sites using a Firefox specific css hack show truncated select elements. See this bug and dupes.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See test cases here or in duplicate.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very scoped patch (adding a minor fractional width to intrinsic size of the combobox).
• String changes made/needed: none
• Is Android affected?: Yes

Comment 24

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/1b641947f6a7

Comment 25

[Anca Soncutean, Desktop QA]

Reproduced with Fx RC 100.0.2 on Windows 10.
Verified fixed with Fx Nightly 102.0a1(2022-05-29) on Windows 10, macOS 12.1 and Ubuntu 20.04.

Comment 26

[Pascal Chevrel:pascalc]

Comment on attachment 9277631 [details]
Bug 1769580 - Add a terrible hack to avoid Netgear's <select>s from overflowing port numbers. r=dholbert

The patch landed in 102 nightly and is thus in beta now.