Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Border arrows are rendered incorrectly #2828

Closed
freaktechnik opened this issue Jun 19, 2018 · 19 comments
Closed

Border arrows are rendered incorrectly #2828

freaktechnik opened this issue Jun 19, 2018 · 19 comments
Assignees
Labels

Comments

@freaktechnik
Copy link

@freaktechnik freaktechnik commented Jun 19, 2018

Making arrows with just one border side set to actually be visible is broken:

https://getbootstrap.com/docs/3.3/components/#dropdowns

@kvark
Copy link
Member

@kvark kvark commented Jun 19, 2018

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.

@freaktechnik
Copy link
Author

@freaktechnik freaktechnik commented Jun 19, 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:
image

Native screenshot:
image

@kvark
Copy link
Member

@kvark kvark commented Jun 19, 2018

Looks fine on my Linux Nightly.

@freaktechnik
Copy link
Author

@freaktechnik freaktechnik commented Jun 19, 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.

@staktrace
Copy link
Contributor

@staktrace staktrace commented Jun 19, 2018

The "firefox screenshot" doesn't use webrender, so none of the webrender-codepath bugs will appear in those screenshots.

@staktrace
Copy link
Contributor

@staktrace staktrace commented Jun 19, 2018

(Also, I can reproduce the problem on macOS nightly)

@gw3583
Copy link
Collaborator

@gw3583 gw3583 commented Jul 10, 2018

I wonder if this will be fixed by #2864 ?

@Darkspirit
Copy link

@Darkspirit Darkspirit commented Jul 10, 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'

@kvark
Copy link
Member

@kvark kvark commented Jul 10, 2018

I can repro (now?) on Linux. Took a capture from a reduced test case locally.

@nical nical added the type: bug label Jul 19, 2018
@cpearce
Copy link

@cpearce cpearce commented Aug 24, 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.

@Darkspirit
Copy link

@Darkspirit Darkspirit commented Sep 1, 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.

@atouchet
Copy link
Contributor

@atouchet atouchet commented Sep 2, 2018

@Darkspirit I've removed that URL as it contained NSFW content that is probably not appropriate to link here.

@emilio
Copy link
Member

@emilio emilio commented Sep 4, 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
Copy link
Member

@emilio emilio commented Sep 4, 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
Copy link
Member

@emilio emilio commented Sep 4, 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
Copy link
Member

@emilio emilio commented Sep 4, 2018

I can take a look at this while I'm looking at related issues.

@emilio emilio self-assigned this Sep 4, 2018
@emilio
Copy link
Member

@emilio emilio commented Sep 4, 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>
@gw3583
Copy link
Collaborator

@gw3583 gw3583 commented Sep 20, 2018

@emilio This one is fixed and can be closed, I think?

@emilio
Copy link
Member

@emilio emilio commented Sep 21, 2018

Yep!

@emilio emilio closed this Sep 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.