2054054 - some borders of styled dropdowns sometimes not painted/shown/visible

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: screenshot: firefox button borders not painted on some sides

Firefox 154.0a1 20260709205531 on Windows 11, DPI at 125%

The borders of some buttons are not rendered on some sides. The affected lines depend on the window position and/or size.

It can be reproduced here with setting a Slack status in one window which is in a fixed position and with some buttons in Firefox's Settings > Privacy and Security where the border on the right is not painted. Bug 2050692 has been fixed, it must have a different regressor.

Comment 1

[Daniel Holbert [:dholbert]]

I tested on Windows 11 (125% scale factor) and haven't been able to reproduce there yet.

However, I was able to reproduce on Ubuntu 26.04 (with 125% scale factor).

In my case:

• I see it the "What's your status?" field, but only after I click into & then out-of that field (which triggers a transition on the box-shadow and border-color).
• If I hover certain nearby elements, the issue goes away.

I'm suspicious that this is a WebRender invalidation/painting bug rather than a layout bug. I know Glenn has been doing some work in the area of border-painting in the last week -- needinfo'ing him.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast showing how the bug manifests on dholbert's Ubuntu 26.04 machine

Comment 3

[Glenn Watson [:gw]]

I have not been able to reproduce this locally at all. I think there is a reasonable chance it will be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1258112 though, which I have just pushed to autoland. Could you check if you're able to repro once that lands?

Comment 4

[Daniel Holbert [:dholbert]]

Yes, I can still reproduce even in builds that include that fix.

That patch was merged to mozilla-central in https://hg-edge.mozilla.org/mozilla-central/pushloghtml?changeset=f40b965f2565f846f2380ad6ce1878abfa201045 which had 88b0f8e6a5925058755d2671bdac5a76d84bd224 as its tipmost commit, and I just launched that mozilla-central build in mozregression (mozregression --launch 88b0f8e6a5925058755d2671bdac5a76d84bd224) and I was still able to repro there.

Here are the STR that I'm using that make this reliably happen, starting from a fresh profile:

1. Launch Firefox in Ubuntu 26.04 with 125% display scaling.
2. Log in at https://sso.mozilla.com/slack
3. Click your avatar and then "Update your status"
4. Full-Page-Zoom to 150% (Hold Ctrl and press + five times). Note that this produces an overall window.devicePixelRatio of 1.875 (when combined with 125% desktop zoom level).
5. Open DevTools (e.g. F12) in its default "bottom-of-window" configuration.
6. If the "What's your status" field happens to have focus, then click a blank space just above it to let it lose focus.

Comment 5

[Daniel Holbert [:dholbert]]

With those STR, I was able to narrow a regression range. Also, opening DevTools didn't turn out to be necessary when I was running mozregression; I think that may have just come up as useful in some of my earlier tests to get the right viewport-size; but with 150% zoom level (at 125% scale factor) and a default sized window, it wasn't necessary.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2a21129467270b93cf6d9584dfece592776bfe52&tochange=35e727d8fda22f3ccfcb1e620484f041002a63c0

--> Regression from Bug 2048146 ("Set layout.disable-pixel-alignment to true on nightlies")

Aryx, could you confirm that toggling layout.disable-pixel-alignment to false makes the issue go away?

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screencast showing that the bug goes away when turning off `layout.disable-pixel-alignment`

(In reply to Daniel Holbert [:dholbert] from comment #5)

Aryx, could you confirm that toggling layout.disable-pixel-alignment to false makes the issue go away?

I confirmed that that pref fixes the issue for me (in my main browsing profile where I can repro at just the right window size/position even without needing 150% full-page-zoom).

See attached screencast.

Comment 7

[Daniel Holbert [:dholbert]]

ni=hiro to take a look since he was watching for regressions (bug 2048146 comment 9).

Comment 8

[Glenn Watson [:gw]]

Thanks for the detailed steps. This still doesn't repro for me, even following those exact steps, unfortunately. There are some other border related patches from Nical that are reviewed and should land in the next day or two [1] [2] [3]. It's plausible one of those may fix the issue you're seeing, from the description. If you find any other reliable repros, please let me know.

[1] https://phabricator.services.mozilla.com/D311799
[2] https://phabricator.services.mozilla.com/D311798
[3] https://phabricator.services.mozilla.com/D311797

Comment 9

[Glenn Watson [:gw]]

When you say "default sized window" above, could you confirm the monitor resolution and what that window size / position is? Maybe I'm failing to repro due to something different there.

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Glenn Watson [:gw] from comment #9)

When you say "default sized window" above, could you confirm the monitor resolution and what that window size / position is? Maybe I'm failing to repro due to something different there.

I don't think the window position matters, based on my testing. (Wayland often puts the window in a semi-random spot, and that doesn't seem to matter on my end.)

I've got my (widescreen) monitor resolution set to 3440x1440 (with 125% scale as noted above).

As to my viewport size, there are two different scenarios that reliably reproduce the issue for me, with mozregression and 125% desktop scaling and 150% browser scaling:
(1) Running with security.sandbox.content.level:0 (which I do sometimes for mozregression purposes to avoid crashes in old builds) -- this adds a warning-toolbar which steals a bit of space from the content viewport. That toolbar appears to be what was responsible for me being able to repro without opening devtools in comment 5 first sentence. It looks like this gives me a viewport of size 853.333px x 599.467px (based on hovering the html element, in DevTools running-in-a-separate-window rather than in a footer-bar).

(2) Running without that^ about:config pref, and just opening devtools with F12. This gives me a viewport of size 853.333px x 467.2px (based on hovering the html element in DevTools inspector).

Note that the viewport sizes here are in CSS pixels, which are wider-than-they-might-otherwise-be because of my 150% full-page-zoom (and of course the 125% desktop zoom).

Comment 11

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

Set release status flags based on info from the regressing bug 2048146

Comment 12

[Daniel Holbert [:dholbert]]

Sorry, I had the viewport sizes swapped between (1) and (2) in my previous comment. I've edited the comment to correct them now.

I don't think the window position matters, based on my testing. (Wayland often puts the window in a semi-random spot, and that doesn't seem to matter on my end.)

Just confirming that window position does not matter (on my end at least) -- I've got a window that's reproducing the bug (via approach (2) from my previous comment, using DevTools as a way to force my viewport to the right size) and it still behaves the same way if I move it to the top-left-most position, top-right-most position, or an arbitrary floating position in the middle of my desktop.

("behaves the same way" = the bug doesn't reproduce on the first load of Slack, but after I open DevTools by simply hitting F12, that shrinks my viewport (to 467.2px) such that the bug does start reproducing with the right edge of the "what's your status" textfield getting clipped.)

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: screencast showing bug not-reproducing on a pageload where I have DevTools open in a separate window, but starting to repro when I attach DevTools to bottom of my window (influencing the height)

Here's a screencast demonstrating scenario (2) from comment 10.

(I was a bit anxious about screencasting Slack in a way that avoids leaking my/others' PII, but I think I managed to do so here; there's just a list of some folks I've DM'd which I'm not concerned about.)

In this screencast:

• I'm using the window-size that mozregression gives me by default.
• I'm not touching security.sandbox.content.level (so I don't have any warning info-bar)
• For the first half of the video, the bug is not reproducing.
• I start out with DevTools open, in separate window. This demonstrate that DevTools itself is not causing the problem, and it lets me demonstrate the initial "good" viewport size when I hover the html element (853.333px x 634.133px, shown in the overlay at the top of the screen at e.g. t=9s)
• Then I attach DevTools to the bottom of my browser, and that impacts the viewport height (as shown via the overlay again at e.g. t=16s, 853.333px x 467.2px). The bug immediately starts reproducing (visible at e.g. t=14s and afterward).

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug start reproducing when the popup becomes scrollable

Aha, I figured out why it's important to have the infobar or devtools present on the window - for the bug to repro, it seems that I need to constrain the height of my viewport enough that the popup gets a scrollbar (overlay scrollbar in my case), so that e.g. a divider-line shows up below "In a meeting" at the bottom.

Here's a screencast of me triggering the bug by very-slowly shrinking the height of my window, which gets at the same situation without relying on those bits of UI to steal height.

In this screencast, the bug becomes visible at t=12s (the right edge of the "What's your status" textbox disappears). This is right when the popup gets small enough to show a dividing line below "In a meeting" and to start showing an overlay scrollbar when hovered.

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing bug reproducing in a window that has no HiDPI of any form, with viewport size of 1279 x 600px

I can also reproduce with no HiDPI of any form (100% scale factor in OS settings, and no full-page zoom), in a viewport that DevTools reports as being 1279px wide and 600px tall.

(I'm reporting the values that are shown when I hover the html element, since those faithfully report fractional pixel values if any are present -- and no fractional portion is present here.)

Here's a screenshot of how my window looks in that scenario (with the right edge of the textbox clipped, reproducing the bug).

Comment 16

[Daniel Holbert [:dholbert]]

Glenn, let me know if the above helps you manage to repro. If not, I'm happy to poke more (or capture logs/diagnostic output/etc). on my end.

Comment 17

[Glenn Watson [:gw]]

I have managed to reproduce, thanks for the details above! Also confirmed so far that it's not solved by any of Nical's patches I mentioned above, and it doesn't appear to be an invalidation issue (still occurs with gfx.webrender.debug.force-picture-invalidation set). Investigating today.

Comment 18

[Glenn Watson [:gw]]

Attachment: minimal.html

Minimized repro case (still depends on window size).

Comment 19

[Hiroyuki Ikezoe (:hiro)]

Thanks for the minimal test case, Glenn. This bug was regressed by 2023886.

Comment 20

[Hiroyuki Ikezoe (:hiro)]

Specifically this change: https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=187e6daff96a27a7e94dcef6a2d996fb973eccd5&tochange=bdb88e138ab84f35dba17f4cd3b23e79447993fb

Comment 21

[Glenn Watson [:gw]]

Minimized wrench yaml case below. Interestingly doesn't seem to be related to an (explicit) clip in this case. Might be a snapping issue or a quad rendering issue, or some intersection (hah) between them.

# Converted from ~/wr-capture/scene-2-0.ron (pipeline (1,4)).
# Spatial tree is reconstructed via nesting:
#   root(1) -> ref-frame(2, snap) -> [ scroll-frame(3) , ref-frame(4 @50.5,305.5) ]
#   ref-frame(4) -> [ scroll-frame(5) , ref-frame(6, non-2d) ]
# Hit-test items from the capture are dropped (they don't render).
# Bracketed indices in comments are the display-item indices from the .ron.
---
root:
  items:
    # [16] ref-frame id 4 @ (50.5, 305.5), identity, is-2d
    - type: reference-frame
      id: 4
      bounds: [50.5, 305.5, 520, 63]
      is-2d: true
      items:
        # [17] stacking-context, spatial 4
        - type: stacking-context
          items:
            # scroll-frame id 5 (frame 520x53, content 520x63), parent spatial 4
            - type: scroll-frame
              id: 5
              bounds: [0, 0, 520, 53]
              content-size: [520, 63]
              items:
                # [25] the input's 1px solid border, clip-chain 4
                - type: border
                  bounds: [28, 5, 464, 43]
                  width: [1, 1, 1, 1]
                  border-type: normal
                  style: solid
                  color: magenta

Comment 22

[Glenn Watson [:gw]]

Although the patch above linked as the regressor may expose this bug, it seems to be somewhere else, I think.

It looks like the display list we get from gecko causes an invariant that we expect (picture cache tiles to end up being device-pixel aligned) to not be true. This causes the composite of the picture cache tile to miss an edge pixel. Not sure yet if this is gecko-side or wr-side.

Comment 23

[Glenn Watson [:gw]]

Attachment: Bug 2054054 - Derive picture cache tile composite clip on the compositor device grid

A tile cache whose world offset is fractional (e.g. a transformed,
flex-centered scroller laid out at an x.5 position) built its composite
clip from the pic->world transform, while the tiles themselves are placed
on the rounded compositor device grid. The half-pixel mismatch between the
two grids clipped the max-side content, dropping the right and bottom edges
(e.g. two sides of a 1px border went missing).

Compute device_clip_rect from the compositor transform instead, rounding
out so it covers rather than crops, matching the grid the tiles are drawn
on. When the tile cache is already device aligned this is identical to the
previous result.

Adds a wrench reftest (tiles/tile-cache-fractional-offset) that renders a
border in a fractional-offset tile cache against a reference whose slice
clip is widened by a background rect so it cannot crop.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4c9e9b99b1a5
https://hg.mozilla.org/integration/autoland/rev/a63285bd6668
Derive picture cache tile composite clip on the compositor device grid r=gfx-reviewers,ahale

Comment 25

[Cosmin Sabou [:CosminS]]

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