Webrender: Border arrows are rendered incorrectly
Making arrows with just one border side set to actually be visible is broken:
freaktechnik
All 19 comments
Could you specify more precisely where the issue is visible on the page? Comparing our rendering with Chromium, I could see that the shadow is a little bit denser, but nothing striking as broken.
kvark
on 19 Jun 2018
The "arrow" with the carret class points to the top right instead of down for me. Though looking at it working when I take a screenshot, this may be a platform issue and I should raise this on bugzilla.
Firefox screenshot:
Native screenshot:
freaktechnik
on 19 Jun 2018
Looks fine on my Linux Nightly.
kvark
on 19 Jun 2018
This is on the latest linux nightly, too. With an nVidia GPU.
The "firefox screenshot does not match native screenshot" thing was exactly the same with the text shadow issue.
freaktechnik
on 19 Jun 2018
The "firefox screenshot" doesn't use webrender, so none of the webrender-codepath bugs will appear in those screenshots.
staktrace
on 19 Jun 2018
(Also, I can reproduce the problem on macOS nightly)
staktrace
on 19 Jun 2018
I wonder if this will be fixed by https://github.com/servo/webrender/pull/2864 ?
gw3583
on 10 Jul 2018
Nope. Still broken on Debian Testing, GTX 1060.
mozregression --repo try --launch 8579dbe6d0db61290f9a34073ba6401b52214fe4 --pref gfx.webrender.all:true startup.homepage_welcome_url:'https://getbootstrap.com/docs/3.3/components/#dropdowns'
Darkspirit
on 10 Jul 2018
I can repro (now?) on Linux. Took a capture from a reduced test case locally.
kvark
on 10 Jul 2018
Minimized test case: https://cpearce.github.io/html-test-cases/webrender-issue-2828-testcase.html
Something like:
<style>
.caret {
border-top:4px dashed;
border-right:4px solid transparent;
border-left:4px solid transparent
}
</style>
<span class="caret"></span>
Changing the border-top to solid fixes the issue, so it may be related to the "dashed" border-top.
cpearce
on 24 Aug 2018
[removed] is affected by this.
Edit: Oh, sorry, yeah one doesn't have the hidexxx cookie by default. I should have linked a subpage.
Darkspirit
on 2 Sep 2018
@Darkspirit I've removed that URL as it contained NSFW content that is probably not appropriate to link here.
atouchet
on 2 Sep 2018
So this is only because the border-style is dashed. I'm not sure what's going on there, but Gecko at least normalizes a bunch of borders in some situations. #3010 introduces NormalBorder::normalize to deal with groove and such borders when they're smaller than two pixels (in which case you can't render anything sensible, and you should just render a solid border).
Depending on what are Gecko and Blink doing in this test-case just changing the border style to be solid in whatever funny situation this is triggered by may make sense.
emilio
on 4 Sep 2018
I suspect very hard that Gecko is changing the start position of the dash in this code block: https://searchfox.org/mozilla-central/rev/c3fef66a5b211ea8038c1c132706d02db408093a/layout/painting/nsCSSRenderingBorders.cpp#1589
emilio
on 4 Sep 2018
Hmm, probably not that one, since the width of the sides is definitely not empty (even though it's transparent). Maybe this: https://searchfox.org/mozilla-central/rev/c3fef66a5b211ea8038c1c132706d02db408093a/layout/painting/nsCSSRenderingBorders.cpp#1668 but would need to step through and see what goes on there.
emilio
on 4 Sep 2018
I can take a look at this while I'm looking at related issues.
emilio
on 4 Sep 2018
So this is because all browsers (except WR / Servo) force discontinuous dashed corners to start with a dash.
You can see it easily resizing the textarea with this html:
<!doctype html>
<style>
textarea {
border: 1px solid black;
border-top: 10px dashed black;
}
</style>
<textarea></textarea>
@emilio This one is fixed and can be closed, I think?
gw3583
on 20 Sep 2018
Yep!
emilio
on 21 Sep 2018
Related issues
jrmuizel
路
5Comments
ivanceras
路
4Comments
Gankra
路
4Comments
fasihrana
路
5Comments
mstange
路
4Comments
Most helpful comment
@emilio This one is fixed and can be closed, I think?