2041504 - Select drop list does not show all values if overflows viewport

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Justin]

Attachment: Fx_droplist_partially_empty.jpg

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

Steps to reproduce:

my viewport is 1261px W x 1230px H
I'm using page https://berean-biblechurch.org/study/

1. on a page that has a very long Select element list near the top so that it overflows the viewport but not by a lot - there seems to be some threshold where the problem happens
2. click the Select button to expose the list

On the above mentioned page, both the first and second lists exhibit the problem.

Actual results:

The list opens with only about the first 75% or so values actually shown, yet the entire list length is shown. The rest of the list is blank.
If you click on the scroll bar then the rest of the values display.

Expected results:

All list values should be visible.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, but is not confident enough to move the bug to that component.

Comment 2

[Shane Hughes [:aminomancer]]

You can reproduce this (at least on Windows) right here on Bugzilla. Go to Edit Bug and open the Component dropdown. If the menu list has enough items, the lower ~20% gets cut off, until you scroll it (mouse wheel works too).

We can't reproduce it on macOS, but we can reproduce on Win11, so we suspect it's a Windows bug.

Comment 3

[Greg Stoll :gstoll]

Weird, I could reproduce it but I started trying to mozregression it and now I can't reproduce it anywhere anymore.

Comment 4

[David Parks [:handyman]]

This is also bug 2035036. I have not been able to reproduce this bug on any site, on any machine. All of the reports so far are for Windows but that's not too meaningful. This report is against Fx151 whereas that one is Fx152.0a1, so this is a bit more informative.

Comment 6

[dduke]

Attachment: testpage-and-screenshot.zip

Continuing from the details of this bug 2051095

I no longer get unrendered items at the end of the list with 152.x (as I did with 151.x) as shown in the screenshot of that bug report. However I found another similar case where selecting the last item and re-opening the drop-down list truncates the rendering horizontally from the right side partially when selecting the last item on the list, provided the labels are long enough character-wise.

I'll update later in the not too distant future to see if this bug still shows up in newer versions.

Attached files: drop-down-list.html and screenshot.png

Comment 7

[Botond Ballo [:botond]]

(In reply to dduke from comment #6)

I no longer get unrendered items at the end of the list with 152.x (as I did with 151.x) as shown in the screenshot of that bug report

If you can reproduce the issue reliably in 151.x, and have a bit of patience to use mozregression, with the "Search for fix" option checked on the last page of the Bisection wizard, to determine which change fixed the issue, that could be very instructive in helping us understand the problem (including potentially the remaining one with the horizontal truncation) better.

Comment 8

[dduke]

Attachment: truncated-bottom-&-right.png

I'll get around to trying out 151.x/152.x portable editions. On another note I updated to 155.0.1 from 152.x and the truncation at the bottom has returned, not just right side.

Comment 9

[dduke]

Noticed something else. When I open a new window (whether regular or private) and test the drop-down-list.html file, I don't get any truncation issue at all. When I open the file as a new tab in an old existing window with many tabs open and test the file then I get the truncation issue at the bottom and right as shown in the screenshot above. However I am not able to reproduce the issue if I open a new window, open dozens of new empty tabs, then open the test file as a new tab in that window to test. So I'm not sure what exact conditions you need to get this to occur, other than a window with many old tabs. Though the browser itself does not have to have been running for a long time, I get the issue even after closing the browser (such as after updating the browser) and recovering the old window (not loading all the old tabs into RAM) and opening the test file in that recovered old window.

I don't feel like closing all my old tabs and starting over any time soon just to see if the issue goes away (it probably will).

I also just tested the following, each in a new window:
Firefox 151.0.2 64-bit Portable Edition - No truncation issues
Firefox 154.0.1 64-bit Portable Edition - No truncation issues
Firefox 155.0.1 64-bit Portable Edition - No truncation issues

Previously I reported, with old window open:
Firefox 151.0.2 32-bit - Truncation at bottom, didn't test horizontally at the time (but most likely both)
Firefox 152.0.x 32-bit - No truncation at bottom, but truncation horizontally at right
Firefox 155.0.1 32-bit - Truncation at bottom and right

In all P.E. versions I installed the same theme and tried to match the below modified prefs from the installed, reopened browser, tested windowed at same size and maximized, and couldn't reproduce the issue:
accessibility.force_disabled
browser.uidensity
gfx.font_rendering.cleartype_params.cleartype_level
gfx.font_rendering.cleartype_params.enhanced_contrast
gfx.font_rendering.cleartype_params.rendering_mode
mousewheel.default.delta_multiplier_y
Not sure if there are any other important modified prefs I missed (full list of modified prefs shown in other bug report). Anyway I don't think these are relevant to the issue.

From my end, these are vague conditions needed to reproduce the truncation issue in the drop-down list:

• Checking the dropdown list in a tab in an old window with many tabs. Does not have to be long-running in RAM.
• At least 880px window height (Reducing the height removes the issue at the bottom. Reducing the width however does not fix the horizontal truncation)

Comment 10

[David Parks [:handyman]]

For anyone who can reproduce this, can you try briefly setting apz.popups_without_remote.enabled=false in about:support? This can help to isolate if it is display port vs other geometry.

Comment 11

[David Parks [:handyman]]

(In reply to David Parks [:handyman] from comment #10)

For anyone who can reproduce this, can you try briefly setting apz.popups_without_remote.enabled=false in about:support? This can help to isolate if it is display port vs other geometry.

Turns out I don't need that after all.

Comment 12

[David Parks [:handyman]]

Attachment: Bug 2041504 - Refresh the displayport base of a reused popup element. r?tnikkel! r=botond!

A select dropdown always reuses the #ContentSelectDropdownPopup element, which
SelectParentHelper creates once per chrome window, and popups in the parent
process get their own APZ. InitializeRootDisplayport() seeded that element's
displayport base with SetDisplayPortBaseIfNotSet(), and nothing removes the
property afterwards, so the base stayed at the geometry of the first dropdown
opened in a given window for as long as that window lived. A later dropdown
taller than the first one was therefore clipped to the stale base, and the
part of its scroll port that fell outside was never painted. It stays blank
until some unrelated repaint fills it in, which is why scrolling the list
fixes it. This patch sets the base unconditionally instead.

The tests open a three option dropdown before a three hundred option one in the
same window (and also try that same case, but pre-scrolled). This was enough
to reproduce the bug without any particular screen size or display scaling in
the pre-scrolled test. The non-pre-scrolled test only failed for certain
monitor configurations (resolution, DPI, etc). Neither should fail anywhere
now.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

I took over it. I revised D325984. That's said, on my Linux box I don't see the original issue at all so that I can't tell whether the original issue is solved by the revised one or not. I could just confirm that the mochitest in D325984 passed locally.

Thank you David Parks for taking care of this bug.

Geez, the Phabricator bot assigned you. :/

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f2fa365dfe90
https://hg.mozilla.org/integration/autoland/rev/d793412e60a1
Refresh the displayport base of a reused popup element. r=botond,tnikkel,layout-reviewers

Comment 15

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/d793412e60a1