Bug 113642 – border-style: double rendering error

• Component: New Bugs
• Status: RESOLVED DUPLICATE

[Benjamin Hell]

Created attachment 195862 [details]
Test case reduction

Double left/right borders (CSS border-style: double) are displayed incorrectly for elements with a differing top/bottom border-style.

I noticed this with block elements directly following each other with no vertical space in-between. If they have double left/right borders, but no top/bottom borders, the double borders of the two different elements are separated by a one pixel wide line (in the background color of the element). This is the case even though there is no space between the elements otherwise. In iOS 6.1.3 Safari there is even a complete border visible, separating the two elements.

I prepared a page (see URL) showing the problem and a dirty workaround. A test case reduction is attached.

I tested with Safari 6.0.3 (8536.28.10, 537+, i.e. Webkit Nightly 2012-03-30), Chrome 26.0.1410.43, Chrome 28.0.1457.0 canary, Safari 6.0.3 (8536.28.10) (all on OS X 10.8.3). The problem is the same everywhere. With Gecko on the other hand, the two elements are rendered such that they cannot be distinguished visually.

[Benjamin Hell]

Created attachment 195863 [details]
Chrome screen shot showing the double border problem

[Benjamin Hell]

Created attachment 195864 [details]
Firefox screen shot not showing the problem

[Takashi Sakamoto]

Created attachment 196112 [details]
Patch

[Takashi Sakamoto]

I think, this patch causes many image failures.
As far as I checked, we could just rebase-line.

[WebKit Review Bot]

Comment on attachment 196112 [details]
Patch

Attachment 196112 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/17346994

New failing tests:
fast/borders/border-mixed-alpha.html
css2.1/t0805-c5521-ibrdr-l-00-a.html
css2.1/t0805-c5521-brdr-l-00-a.html
css2.1/t0805-c5519-brdr-r-00-a.html
css1/box_properties/border_right.html
css1/box_properties/border_left.html
css2.1/t0805-c5519-ibrdr-r-00-a.html
css1/box_properties/border_left_inline.html
css1/box_properties/border_right_inline.html

[WebKit Review Bot]

Created attachment 196122 [details]
Archive of layout-test-results from gce-cr-linux-07 for chromium-linux-x86_64

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-07  Port: chromium-linux-x86_64  Platform: Linux-3.3.8-gcg-201212281604-x86_64-with-GCEL-10.04-gcel_10.04

[Simon Fraser (smfr)]

Comment on attachment 196112 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=196112&action=review

> Source/WebCore/rendering/RenderObject.cpp:946
> +                        // Offseting the border by 1 seems to cause the following bug:
> +                        // https://bugs.webkit.org/show_bug.cgi?id=113642

There's no point leaving a comment that relates to code that was removed.

Does this affect the behavior of double borders when top and bottom borders are visible? Did you look through svn history to see why the +1 was added?

[Takashi Sakamoto]

Created attachment 196323 [details]
Patch

[Takashi Sakamoto]

Created attachment 196327 [details]
Patch

[Takashi Sakamoto]

Comment on attachment 196112 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=196112&action=review

Thank you for reviewing.

>> Source/WebCore/rendering/RenderObject.cpp:946
>> +                        // https://bugs.webkit.org/show_bug.cgi?id=113642
> 
> There's no point leaving a comment that relates to code that was removed.
> 
> Does this affect the behavior of double borders when top and bottom borders are visible? Did you look through svn history to see why the +1 was added?

I see.
I removed the comment and updated layout test to have top- and bottom- double borders. I think, its expected.png looks ok.
I also tried to find where the +1 came from. So ... it came from khtml, c.f.
http://trac.webkit.org/browser/trunk/WebCore/khtml/rendering/render_object.cpp?rev=1175#L270

Is it better to see khtml's history?

[WebKit Review Bot]

Comment on attachment 196327 [details]
Patch

Attachment 196327 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/17328904

New failing tests:
fast/borders/border-mixed-alpha.html
css2.1/t0805-c5521-ibrdr-l-00-a.html
css2.1/t0805-c5521-brdr-l-00-a.html
css2.1/t0805-c5519-brdr-r-00-a.html
css1/box_properties/border_right.html
css1/box_properties/border_left.html
css1/box_properties/border_right_inline.html
css1/box_properties/border_left_inline.html
css2.1/t0805-c5519-ibrdr-r-00-a.html

[WebKit Review Bot]

Created attachment 196332 [details]
Archive of layout-test-results from gce-cr-linux-01 for chromium-linux-x86_64

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: gce-cr-linux-01  Port: chromium-linux-x86_64  Platform: Linux-3.3.8-gcg-201212281604-x86_64-with-GCEL-10.04-gcel_10.04

[Rüdiger Cordes]

Another border problem: Bug 124441

[Joseph Pecoraro]

Looks like this fix landed eventually as part of bug 129226. Removing patch flags and duplicating. If you still wanted, you could still try to land the test!

*** This bug has been marked as a duplicate of bug 129226 ***