Bug 113642 - border-style: double rendering error
Summary: border-style: double rendering error
Status: RESOLVED DUPLICATE of bug 129226
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.8
: P2 Normal
Assignee: Takashi Sakamoto
URL: http://bhell.github.com/misc/border-s...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-30 12:18 PDT by Benjamin Hell
Modified: 2015-11-12 13:08 PST (History)
11 users (show)

See Also:


Attachments
Test case reduction (335 bytes, text/html)
2013-03-30 12:18 PDT, Benjamin Hell
no flags Details
Chrome screen shot showing the double border problem (25.17 KB, image/png)
2013-03-30 12:21 PDT, Benjamin Hell
no flags Details
Firefox screen shot not showing the problem (29.29 KB, image/png)
2013-03-30 12:22 PDT, Benjamin Hell
no flags Details
Patch (6.61 KB, patch)
2013-04-02 03:28 PDT, Takashi Sakamoto
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-07 for chromium-linux-x86_64 (3.37 MB, application/zip)
2013-04-02 04:59 PDT, WebKit Review Bot
no flags Details
Patch (6.45 KB, patch)
2013-04-03 04:20 PDT, Takashi Sakamoto
no flags Details | Formatted Diff | Diff
Patch (5.67 KB, patch)
2013-04-03 04:30 PDT, Takashi Sakamoto
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from gce-cr-linux-01 for chromium-linux-x86_64 (2.57 MB, application/zip)
2013-04-03 05:30 PDT, WebKit Review Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Hell 2013-03-30 12:18:55 PDT
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.
Comment 1 Benjamin Hell 2013-03-30 12:21:39 PDT
Created attachment 195863 [details]
Chrome screen shot showing the double border problem
Comment 2 Benjamin Hell 2013-03-30 12:22:36 PDT
Created attachment 195864 [details]
Firefox screen shot not showing the problem
Comment 3 Takashi Sakamoto 2013-04-02 03:28:22 PDT
Created attachment 196112 [details]
Patch
Comment 4 Takashi Sakamoto 2013-04-02 03:29:33 PDT
I think, this patch causes many image failures.
As far as I checked, we could just rebase-line.
Comment 5 WebKit Review Bot 2013-04-02 04:59:12 PDT
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
Comment 6 WebKit Review Bot 2013-04-02 04:59:16 PDT
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
Comment 7 Simon Fraser (smfr) 2013-04-02 09:04:25 PDT
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?
Comment 8 Takashi Sakamoto 2013-04-03 04:20:27 PDT
Created attachment 196323 [details]
Patch
Comment 9 Takashi Sakamoto 2013-04-03 04:30:00 PDT
Created attachment 196327 [details]
Patch
Comment 10 Takashi Sakamoto 2013-04-03 04:33:04 PDT
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?
Comment 11 WebKit Review Bot 2013-04-03 05:29:56 PDT
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
Comment 12 WebKit Review Bot 2013-04-03 05:30:00 PDT
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
Comment 13 Rüdiger Cordes 2013-11-15 16:32:58 PST
Another border problem: Bug 124441
Comment 14 Joseph Pecoraro 2015-11-12 13:08:39 PST
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 ***