Open Bug 1473083 Opened 6 years ago Updated 2 years ago

div with border-radius has visible "halo"/"fringe" of background color, outside the border

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional

People

(Reporter: dholbert, Unassigned)

References

Details

(Keywords: regression, testcase, Whiteboard: [gfx-noted])

Attachments

(11 files)

testcase 1
(deleted), text/html
Details
screenshot of testcase 1 in Firefox Nightly
(deleted), image/png
Details
screenshot of testcase 1 in Firefox Nightly, zoomed in 10x (clearly showing the buggy fringe)
(deleted), image/png
Details
screenshot of testcase 1 in Chrome, zoomed in 10x (no fringe)
(deleted), image/png
Details
screenshot of bug manifesting on Google Inbox, in Firefox Nightly
(deleted), image/png
Details
testcase 2 (lightgray border)
(deleted), text/html
Details
screenshot of testcase 2 in Firefox Nightly, zoomed in 10x (clearly showing the buggy fringe)
(deleted), image/png
Details
screenshot of black-bordered testcase in Firefox Nightly, zoomed in 20x (clearly showing the buggy fringe)
(deleted), image/png
Details
screenshot of bug on "New" badge on nextdoor.com
(deleted), image/png
Details
testcase 3 (from "Notifications" badge on Nextdoor)
(deleted), text/html
Details
screenshot of testcase 3
(deleted), image/png
Details
Attached file testcase 1 (deleted) —
STR: 1. Load attached testcase. EXPECTED RESULTS: Should render as a simple Rounded red rectangle. ACTUAL RESULTS: There's a visible red fringe/halo around the rectangle. If I take a screenshot and zoom in, I can see that (moving outwards) there are red pixels in the middle (the background), and then lighter/white pixels (the rounded border) and then redder pixels again outside of that border! Those outermost red pixels should not be redder than the border. Chrome gives EXPECTED RESULTS here. (FWIW, I originally noticed this at Google Inbox, when I typed a bogus email address into the "to" field of a message that I was composing. The bogus email address gets a red background with a white rounded border, and the red background visibly leaks past the border to create a weird halo as in the attached testcase.)
I'm using latest Nightly on 64-bit Ubuntu 18.04 (Linux) Nightly version: 63.0a1 (2018-07-03) (64-bit)
Here's the screenshot, zoomed in 10x (with Gimp, using interpolation set to "none" to simply scale up the pixels). As you can see, there are reddish pixels outside of the whitish border on each of the rounded corners.
Attachment #8989493 - Attachment description: same screenshot, zoomed in 10x → screenshot of testcase 1 in Firefox Nightly, zoomed in 10x (clearly showing the buggy fringe)
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fafaf614791f&tochange=658fad825c36 Looks likely to be a regression from bug 704399 (which was addressing an issue where we failed to paint the background for the area all the way up to the border). Seems like that bug's patch made us paint the background further out, and a bit too far in fact.
Blocks: 704399
Keywords: regression, testcase
(In reply to Daniel Holbert [:dholbert] from comment #1) > I'm using latest Nightly on 64-bit Ubuntu 18.04 (Linux) I can reproduce in Firefox release on Win10 & Mac HighSierra, too (via browserstack). So this isn't Linux-specific.
OS: Unspecified → All
Hardware: Unspecified → All
If I am reading the commens in the regressing bug correctly, it sounds like we expected this behaviour? (7 years is a long time though.)
Flags: needinfo?(bzbarsky)
Priority: -- → P3
Whiteboard: [gfx-noted]
It doesn't look to me like we were expecting this... Bug 704399 comment 5 did mention something similar (ugly fringes), but only in cases with *transparent* borders. And bug 704399 comment 6 indicated that the patch was restricted to opaque borders & hence wasn't expected to cause that problem, IIUC. But unfortunately we do still get the problem with fully-opaque borders, as shown here.
Attached file testcase 2 (lightgray border) (deleted) —
Just to take transparent/"transparent-ish" (same color as background) border dependencies out of the picture -- here's another testcase, with a lightgray border now -- i.e. a *different color from the page background*. This has the issue as well, though it's not as easy to see. I'll post a zoomed-in screenshot to illustrate it.
Here's testcase 2 zoomed in 10x. As with testcase 1, you can see that there's a solid not-red-at-all rounded border -- but then outside that, the pixels get reddish again. It looks like maybe what's happening is that we're antialiasing the curved border (making the outer pixels partially transparent), and we're compositing that antialiased border with the red background underneath it, so some red gets blended into those antialiased border-pixels...?
Here's a screenshot of an alternate testcase (not attached) with a black border rather than gray or white, with the screenshot zoomed in 20x (extra high-res). Some of fringe is visibly darker here, so I think it's likely that these are indeed antialiased mostly-transparent border pixels.
I would expect that this is in fact all about antialiasing behavior, yes... But we should check whether we're in fact painting the border further out than the background; we shouldn't do that.
Flags: needinfo?(bzbarsky)
Marking fix-optional for 64. We could still take a patch for 65, and if it's verified and doesn't seem risky, could still take fixes for 64 as well.
status-firefox64: affected → fix-optional
Happy to take a patch in nightly; if it seems low risk enough please feel free to request uplift to 65 beta.
status-firefox65: affected → fix-optional

I'm seeing this issue on the "New" badges on nextdoor.com, for what it's worth. Here's a screenshot.

Here's the HTML they're using, roughly (which is roughly equivalent to the already-attached testcases here, and which triggers the issue for me in a local testcase):

<!DOCTYPE html>
<style>
  .new-badge {
      display: inline-block;
      border: 1px #F9F9FA solid;
      border-radius: 4px;
      background-color: #0099BA;
      color: white;
  }
</style>
<body>
  <div class="new-badge">New</div>

Can this still be reproduced or can we close this Bug. Works for me by now

Flags: needinfo?(dholbert)

Yes, this can still be reproduced. If I load testcase 1 in current Nightly 98.0a1 (2022-01-13) and inspect with a zoom tool (e.g. the Gnome Accessibility "Zoom" Feature, or take a screenshot and zoom in in a graphics editor), then it's clear that there are reddish pixels outside the white border, as shown in comment 3. (While I'm here, I'll drop the mention of Google Inbox from the bug summary, since that product no longer exists.)

Flags: needinfo?(dholbert)
Summary: div with border-radius has visible "halo"/"fringe" of background color, outside the border (e.g. at Google Inbox) → div with border-radius has visible "halo"/"fringe" of background color, outside the border

Also worth noting: this bug is only reproducible if the testcase's border is 1 display pixel in thickness.

(e.g. with the attached testcases which use 1 CSS pixel as the border width, this bug is only reproducible if you have 100% pixel-scaling, i.e. no High-DPI configuration at all. So the bug doesn't reproduce if I load testcase 1 on my 4K Samsung monitor, configured at max-resolution with 200% pixel scaling in Ubuntu. However, if I modify the testcase to use 0.5px as the border-width (i.e. one display pixel), then the bug does reproduce on that monitor.)

I think this is just because the "fringe" here is just one or two display-pixels of overflowing background-color. So if the border is more than one display pixel of thickness, then there's no noticeable jump between the border and the overflowing background-color.

I looked at this code as part of other work, and it seems that the border painting check added in bug 704399 has not been used at all for a while now. WebRender does check if there is a border item following a background item1, but does not use the flag.

Just noticed this on Nextdoor.com again, this time on the "unread notifications count" badge.

Here's a reduced testcase of this instance, using the styling taken directly from the site.

Attached image screenshot of testcase 3 (deleted) —

Here's what testcase 3 looks like for me, on Ubuntu 22.04 with 100% pixel scaling (no HiDPI).

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: