1943386 - Extension popup UI isn’t scrollable/is cropped/doesn't go all the way down, if it doesn’t fit entirely on the screen with enlarged display Windows settings

Status: NEW

(WebExtensions :: Frontend, defect, P3)

Description

[gwarser]

https://github.com/uBlockOrigin/uBlock-issues/issues/3014

Description

I have an issue in the popup UI's firewall section: the scrollbar does not go all the way down (it seems cropped?).

For example, on this website, I have this firewall list:
https://github.com/uBlockOrigin/uBlock-issues/assets/45640841/7fc47be2-892c-4962-9bb2-3e2511bab8ef
But it's missing the last element, only visible when expanding All (the last sub-element is still missing) or when using filters:
https://github.com/uBlockOrigin/uBlock-issues/assets/45640841/d3a240d9-6eba-49e3-8799-d548d890bbc7

It only seems to happen when the add-on is put on the bookmark bar, the main toolbar seems to work properly:
https://github.com/uBlockOrigin/uBlock-issues/assets/45640841/782542c2-1aba-4b06-98a7-77bebebeaef4

A specific URL where the issue occurs.

https://honkai-star-rail.fandom.com/wiki/Trailblazer/Media?file=Honkai-_Star_Rail_Second_Closed_Beta_Trailer_-_Your_Choice_-_Honkai-_Star_Rail

Steps to Reproduce

1. put the add-on icon on the bookmark bar
2. enable the menu bar
3. open the pop-up
4. (wait until everything is loaded)
5. try to scroll all the way down

Expected behavior

To be able to scroll all the way down and see all filters

Actual behavior

I was unable to see and enable the last website (which enables the video viewer)

---

https://github.com/uBlockOrigin/uBlock-issues/issues/3504

Description

I'm using uBlock Origin in Advanced Mode, which allows me to monitor and block individual requests from websites dynamically. However, I’ve encountered a usability issue:
On some websites with many requests to third-party domains, the dynamic filtering panel doesn't show the last few requests.
There’s no way to scroll to view or manage these hidden requests.
This makes it difficult to block or allow specific requests when the list is long, especially on sites that make a high volume of requests.

A specific URL where the issue occurs.

it happens on every site with many third-party requests, here's an example: https://suno.com/song/48b1ea72-7ccd-446d-a3a4-54c699915b21

Steps to Reproduce

Enable Advanced Mode in uBO.
Visit a website that makes many third-party requests (e.g., ad-heavy or analytics-heavy sites).
Open the Dynamic Filtering Panel.
Notice that the last few requests are inaccessible even if you scroll

Expected behavior

The dynamic filtering panel should include a scrollbar or some mechanism to access all requests, regardless of how many are made by the site. For accessing all requests, regardless of how many the site makes

Actual behavior

The panel displays only a fixed number of requests, with no ability to scroll or view the remaining ones. The last few requests become inaccessible, and it is impossible to view

https://github.com/user-attachments/assets/af41cc68-5ec0-446a-9515-54e30adc8834

---

https://github.com/uBlockOrigin/uBlock-issues/issues/3529

Description

When people with visual impairment set lower screen resolution, higher display scale and larger text view, in order to see better the screen content, uBO main UI isn’t scrollable, if it doesn’t fit entirely on the screen, leaving its bottom part inaccessible.

A specific URL where the issue occurs.

everywher

Steps to Reproduce

1. Go to Windows settings --> System --> Screen.
2. Change screen resolution to 1280x800, display scale (DPI) to 125% and text size to 150%.
3. Go to Firefox display settings and change the font size to 16.

Expected behavior

uBO main UI is scrollable on Firefox, if it doesn’t fit entirely on the screen, as already happens on Edge.

Actual behavior

uBO main UI isn’t scrollable on Firefox, leaving its bottom part inaccessible.

---

Explanaion of what's happening by gorhill:

This cannot be fixed by uBO, uBO is given a viewport to render in by the browser, and that viewport extends beyond the screen. The browser is causing the viewport to extend beyond the screen, it's out of control of uBO. Same as https://github.com/uBlockOrigin/uBlock-issues/issues/1100.

and

To confirm, using the browser tools, the height of the popup panel container set by the browser is 544px, but the viewport inside that container is 600px, more specifically, the panelview is 631px x 544px, then the stack element in it is 631px x 600px. These are completely out of uBO's view, 600px just what it's being given.

and

The browser is giving uBO a container to render its popup panel and uBO doesn't know it's off screen, only the browser knows. The fix has to be browser-side, it needs to ensure the container in which uBO is told to render to not extend beyond the screen.

Comment 1

[Alex Cornestean]

For issue https://github.com/uBlockOrigin/uBlock-issues/issues/3014.

I could not reproduce the issue on the latest Nightly (136.0a1/20250126212632), Beta (135.0b9/20250124091819) nor Release (134.0.2/20250120135430) on Windows 10 x64 and Ubuntu 24.04 LTS, both when the add-on button is on the toolbar and in the extensions panel.

I accessed https://honkai-star-rail.fandom.com/wiki/Trailblazer/Media?file=Honkai-_Star_Rail_Second_Closed_Beta_Trailer_-_Your_Choice_-_Honkai-_Star_Rail, opened the add-on pop-up and then expanded the pop-up to see the filtering panel. All requests are properly shown, the list can be scrolled to the end and the panel is not cropped at the bottom. See screenshot for more details.

For issue https://github.com/uBlockOrigin/uBlock-issues/issues/3504.

I also could not reproduce the issue on the latest Nightly (136.0a1/20250126212632), Beta (135.0b9/20250124091819) nor Release (134.0.2/20250120135430) on Windows 10 x64 and Ubuntu 24.04 LTS, both when the add-on button is on the toolbar and in the extensions panel.

For this, I accessed https://edition.cnn.com/ which is request heavy and did as in the previous scenario. All requests are properly shown, the list can be scrolled to the end and the panel is not cropped at the bottom.

For issue https://github.com/uBlockOrigin/uBlock-issues/issues/3529.

I reproduced the issue on the latest Nightly (136.0a1/20250126212632), Beta (135.0b9/20250124091819) and Release (134.0.2/20250120135430) on Windows 10 x64 both when the add-on button is on the toolbar and in the extensions panel.

I accessed both the previous websites under the specific conditions mentioned in the issue and indeed the filtering panel does not show the entire list of requests and is cropped at the bottom (about 7 requests are missing compared to normal settings). See attached screenshot.

Note that, under 1080p resolution, 100% scaling and 100% text size, the issue does not occur.

I will be setting the report to NEW (despite not managing to reproduce the first two issues on my end) for the third issue as it does represent a usability issue under those specific conditions.

Comment 2

[Alex Cornestean]

Attachment: 3014+3504.png

Comment 3

[Alex Cornestean]

Attachment: 3529.png

Comment 4

[gwarser]

For issue https://github.com/uBlockOrigin/uBlock-issues/issues/3014.
...
For issue https://github.com/uBlockOrigin/uBlock-issues/issues/3504.

I can still reproduce after setting resolution to 1280x720. Firefox 134.0.2.

(From my experience, decreasing the resolution is a universal solution used by people with poor eyesight, to make everything on screen larger.)

Comment 5

[Alex Cornestean]

I checked each individual issue linked in Comment 0 separately based on the descriptions for each.

Issues 3014 and 3504 were tested with 1920x1080, 100% scaling and 100% text size as I assumed the cropped panel happened with these settings too. My mistake. And as I described, I could not reproduce under these conditions.

Issue 3529 was the only one for which I lowered the resolution, changed scaling and text size, but I used the same websites as for the other issues. And I could reproduce the issue under those conditions.

Indeed, the panel is cropped for all above issues when the resolution is low enough, with and without scaling or text size. For example, on my 15 inch laptop display, the panel is cropped when resolution is set lower than 1280x720 at 100% scaling (it happens starting with 1280x600) and 100% text size. If I increase scaling, the resolution at which the issue occurs, goes up (1280x768 @ 125% scaling).

Comment 6

[Rob Wu [:robwu]]

Luca is going to look into the STR, to confirm the issue and see what relevant internal parts are responsible for this behavior. And if applicable, summarize the details for a needinfo to Emilio.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

I confirmed that I can reproduce this issue on windows using the STR from comment 0 (tested in a windows VM by setting the resolution at 1280x800, scaling to 150% and the https://honkai-star-rail.fandom.com from comment 0).

Then I managed to also reproduce it on Linux by:

• creating a Xephyr Xorg display (started using the following options Xephyr -ac -br -noreset -resizeable -screen 1280x800 -dpi 200 :11)
• starting a local Nightly build into that Xephyr Xorg display using DISPLAY=:11 mach run -start-debugger-server 6001
• then in the Nightly running inside Xephyr setting in about:config the pref layout.css.devPixelsPerPx to 1.5.
• and finally connecting to that Nightly instance from an about:debugging tab opened in a Firefox instance outside of that Xephyr Xorg display (so that inspecting what was going on was easier with more screen space available)

I then confirmed that 600px is being set on the browser element where the uBlock popup is being loaded (and the parent stack adapting to that height too) as mentioned in comment 0 quotes from the github issue comments.

Seeing 600 looked suspicously the same as the value we set as the max height we allow the browser action popup to be (see here in ExtensionPopups.sys.mjs and then propagated to the child process where the popup leaves here in ext-browser-content.js), and so I felt it was worth digging a bit more on that aspect and what role it may have in triggering this bug.

Test behavior on maxHeight set to 450 in ExtensionPopups "Extension:InitBrowser" message

In my local build I tried to set a lower height value than 600 (e.g. 450) here ExtensionPopups.sys.mjs to see if that was going to change the current behavior, but the firewall scrollable area from the ublock popup was still going out of the visible part of the popup panel.

Inspecting the element browser element hosting the browserAction popup page (the one with class "webextension-popup-browser") confirmed that the style attribute was actually set to width: 631px; min-width: 631px; height: 450px; min-height: 450px; and so the lower height value was actually being enforced on the browser element (while height and min-height were set to 600px with the value currently set in ExtensionPopups.sys.mjs).

Despite that, inspecting the firewall part of the uBlock popup page DOM element confirmed that its height was still 600px, and so some of the entries were still out of the visible part of the popup as reported by this bug report.

Test behavior on setting max-height to 450px in uBlock popup-fenix.css

What I observed in the previous test made me think that it was worth also digging a bit more on uBlock stylesheets side, and looking for any rule that may have had 600px as height, min-height or max-height and found that there is a max-height set here in popup-fenix.css, suspiciously part of the urls for the DOM element with id firewall:

#firewall {
  ...
  max-height: 600px
  ...
}

I felt that may potentially have some role in triggering this bug and so I unpacked the uBlock xpi, changed only that single rule to set max-height to 450px and loaded the unpacked ublock with the css tweak to compare what was going to be the behavior compared with the original uBlock xpi where that is set to 600px.

This time the firewall part of the popup was showing all elements when scrolling down, and it looked to be the case also by trying it again in a build were I reverted the change on the maxHeight value coming from ExtensionPopups.sys.mjs.

Then I also tried if all the entries in the firewall list were visible if I was setting #firewall's max-height to 100vh (to try to just set the max-height to the max vertical space available in the viewport) and that seems to also be working (without any change on the ExtensionPopups.sys.mjs).

Thoughts based on what observed so far

The 600px value used as maxHeight on the ExtensionPopups.sys.mjs may have been hardcoded with the assumptions that it was going to be low enough based on the most common resolutions used on desktop system nowdays, and I was starting to wonder if it would be worth to consider to recompute that in certain conditions (e.g. when that much screen space may not be actually available, as in the scenario I was testing).

The fact that setting a lower value on the ExtensionPopups.sys.mjs maxHeight didn't actually fix the visibility issue for the uBlock firewall list (without also changing the #firewall's max-height) made me feel a bit on the fence about how valuable that would be in practice, especially given that not hardcoding the max-height to 600px on the uBlock side but using a viewport size one does instead seem to help to fix the issue.

If there are no unwanted side-effects on solving the issue on the extension css side (e.g. using the 100vh as max-height in css rule that need to enforce a part of the popup to not get more vertical space than actually available), that seems to be potentially a reasonable fix to apply on the uBlock side.

As a side note, I wouldn't exclude that with the other STRs that I couldn't reproduce locally (the ones that doesn't need to change resolution, scaling etc.) setting the #firefox max-height to 100vh may not fix the issue, but I couldn't double-check that without an STR that was making me hit the issue locally and so I focused on gathering as much as possible with the one that worked for me.

I'll touch base with the other teammates in the next triage meeing to gather also their perspective given what I managed to collect so far (and also double-check if we still feel that needinfo-ing Emilio may help gathering some other ideas/perspective).

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:robwu, could you have a look please?

For more information, please visit BugBot documentation.

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi gorhill,
as mentioned in comment 7, I took a look into this issue a few weeks ago, and based on what I managed to gather so far it looks that uBlock's firewall scrollable element would still be cropped at 600px even if we would be applying changes on the Firefox side (around the action's popup max allowed height used from inside ExtensionPopups.sys.mjs), and that seems to be a side-effect of the additional max-height: 600px explicitly set on the #firewall element from popup-fenix.css. Changing that to 100vh on the popup-fenix.css side looked to be enough to make uBlock's firewall element to be fully scrollable and not get cropped.

would you mind to double-check if that seems like a reasonably acceptable fix to be applied on the uBlock side?

As a side note: based on what I've been able to observe while looking into this locally, that change also doesn't seem to have any unwanted side-effects, but I could also ask our QA to help us to test it out on more builds and screen sizes if that may be helpful to verify that more explicitly and broadly.

Comment 10

[[e-mail]]

Attachment: max-height set to 100vh

Comment 11

[[e-mail]]

Attachment: max-height set to 600px

Comment 12

[[e-mail]]

Sorry for the delay, I was not able to repond back then and then forgot about it.

I can change to 100vh. The side effect of this change is that it may causes a smaller height for the popup panel when the basic pane is shorter -- something which may happen when users disable some sections of the popup panel through advanced settings. (images attached).

Using 100vh essentially means to let the basic pane (right section) to dictate the height of the left pane (firewall).

But I will assume that this is a edge case, and it comes down to pick which edge cases win -- people customizing the basic pane through advanced settings versus people having a screen resolution which can't accommodate the full height of the popup panel.

---

I suspect changing max-height to 100vh is going to upset a lot of people because even without customizing the popup panel, the firewall list ends up sorter than it is now, and I've had requests in the past to make the firewall pane higher because many sites require listing a lot of 3rd-party domains.

On second thought, I might prefer to come up with an advanced setting for people suffering the lack of vertical space, in which case the advanced setting would cause the popup panel code to set max-height to 100vh programmatically so that only those suffering the issue would be affected by the side effects of using such value.

Comment 13

[[e-mail]]

Attachment: max-height set to 600px with no panel customization

Comment 14

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi gorhill,
Based on the details gathered so far by investigating this bug, do you think that from a uBlock's perspective we could close this bug (e.g. as a completed developer outreach, with a potential fix to be applied on the extension css side) or are there some additional thoughts / ideas for fixing it on the Firefox side that may be worth looking further into?

Comment 15

[[e-mail]]

You can close, if the issue is brought back in uBO's repo, I will probably go with a custom advanced setting to dictate how the popup height should be set.

Comment 16

[Dimitris Kalaboukas]

The issue affects all Firefox extensions without exceptions. So, it’s caused by the browser’s provided container for the UI of extensions, which is totally unscrollable in such display configurations.

https://github.com/uBlockOrigin/uBlock-issues/issues/3504#issuecomment-2564811872

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:robwu, could you have a look please?

For more information, please visit BugBot documentation.

Comment 18

[Rob Wu [:robwu]]

Attachment: extension-test-case.zip

This issue is platform-independent. The report is about Windows, Luca verified on Linux in comment 7. And I just reproduced on a Macbook Pro laptop whose screen height is around 1000px.

STR:

1. Open the attached extension.
2. Drag the window to the middle of the screen.
3. Open the extension popup. It declares content with a large height, as well as markers at the start&end of the body.
4. Look for the bottom of the viewport as explained in the test extension (the popup renders an element in the corner of the viewport with position:fixed;bottom:0;).

Expected:

• The corner of the viewport should be visible.

Actual:

• The corner/bottom of the viewport is clipped.

When the extension button is in the middle of the screen, and the extension popup is opened, there will clearly be less than 500px space. However, we allow a maximum height of 600px (source), which is assigned as the height and max-height CSS properties of the popup <browser> (source). The parent element (<stack>)'s parent element is a <panelview>, whose height is limited to the amount of space available.

When the amount of available height is less than the size of the <browser>, the bottom of its content is clipped, resulting in the observed bug here.

Comment 19

[Rob Wu [:robwu]]

Suggested fix:

• Logic to change: https://searchfox.org/firefox-main/rev/0a0abe40bbe8cc587e6316541d7c59042fb9ae54/browser/components/extensions/ExtensionPopups.sys.mjs#419-420
• when the height exceeds the available space, use the available space instead.
• a trivial way to verify the available space is to check this.viewNode.offsetHeight (viewNode is the panelview element). The downside is a forced reflow on every resize.
• an alternative is to precompute the available space above/below the extension button and use that to configure the initial max height and adjust the height if needed, e.g. at https://searchfox.org/firefox-main/rev/0a0abe40bbe8cc587e6316541d7c59042fb9ae54/browser/components/extensions/ExtensionPopups.sys.mjs#628-642

Note: there is logic keyed by "fixedWidth", but that is dead code since the changes from bug 1783972.