Opened 3 years ago

Closed 3 years ago

#17062 closed bug (fixed)

WebPositive rendering issues - borders rendering incorrectly

Reported by: kallisti5 Owned by: pulkomandy
Priority: high Milestone: R1/beta3
Component: Kits/Web Kit Version: R1/beta3
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by kallisti5)

Here's a good test candidate of the rendering issues in WebKit after haikuwebkit 1.8.1.

Compare:

  • Otter Browser
  • WebPositive

Test site:

Notable issues:

  • Table borders black line instead of specified color

Reproduction:

Black border seen instead of red:

<html>
<body style="background-color: #DDD">
<table style="color: #111; width: 100%">
<tr><td style="border: 1px #ff0000 solid;">Name</td><td>Place</td></tr>
<tr><td>Tickle</td><td>Pickle</td></tr>
</table>
</body>
</html>

Proper red dashed border seen:

<html>
<body style="background-color: #DDD">
<table style="color: #111; width: 100%">
<tr><td style="border: 1px #ff0000 dashed;">Name</td><td>Place</td></tr>
<tr><td>Tickle</td><td>Pickle</td></tr>
</table>
</body>
</html>

Change History (12)

comment:1 by kallisti5, 3 years ago

Description: modified (diff)

comment:2 by kallisti5, 3 years ago

Component: Applications/WebPositiveKits/Web Kit

comment:3 by kallisti5, 3 years ago

Description: modified (diff)
Summary: WebPositive rendering issuesWebPositive rendering issues - borders rendering incorrectly

comment:4 by kallisti5, 3 years ago

Description: modified (diff)

comment:5 by kallisti5, 3 years ago

Description: modified (diff)

comment:6 by kallisti5, 3 years ago

Changing SolidStroke in Source/WebCore/platform/graphics/haiku/GraphicsContextHaiku.cpp from B_SOLID_HIGH to B_MIXED_COLORS doesn't seem to solve it. Nor does adding NotImplemented() for Solid.

comment:7 by kallisti5, 3 years ago

Priority: blockerhigh

This may be a webkit bug and not a bug in our actual port. If you put two tables in a single HTML document like below... and swap dashed first vs solid first...

Renders improperly

<html>
<body style="background-color: #DDD">
<table style="color: #111; width: 100%">
<tr><td style="border: 1px #ff0000 solid;">Name</td><td>Place</td></tr>
<tr><td>Tickle</td><td>Pickle</td></tr>
</table>
<table style="color: #111; width: 100%">
<tr><td style="border: 1px #ff0000 dashed;">Name</td><td>Place</td></tr>
<tr><td>Tickle</td><td>Pickle</td></tr>
</table>
</body>
</html>

Renders properly

<html>
<body style="background-color: #DDD">
<table style="color: #111; width: 100%">
<tr><td style="border: 1px #ff0000 dashed;">Name</td><td>Place</td></tr>
<tr><td>Tickle</td><td>Pickle</td></tr>
</table>
<table style="color: #111; width: 100%">
<tr><td style="border: 1px #ff0000 solid;">Name</td><td>Place</td></tr>
<tr><td>Tickle</td><td>Pickle</td></tr>
</table>
</body>
</html>

That makes me think this is a webkit master regression over an issue on our end.

comment:8 by pulkomandy, 3 years ago

There's no reason WebKit would have a regression so big. Also this appeared as I rewrote the GraphicsContextHaiku class to the new API. Pretty sure I missed something while doing that and the graphics state is not the expected one.

Maybe it's simply missing some initialization of the initial view state?

comment:9 by jessicah, 3 years ago

Version 0, edited 3 years ago by jessicah (next)

comment:10 by jessicah, 3 years ago

Okay, so the case in comment:7 is unaffected by that commit. Reverting it had no effect on the second table's incorrectly rendered borders. Therefore that commit is safe to apply.

comment:11 by jessicah, 3 years ago

So, pushed another tiny patch that addresses kallisti's test cases.

comment:12 by kallisti5, 3 years ago

Resolution: fixed
Status: newclosed

I can confirm this one is resolved. Nice work!! Things looking a lot better.

Note: See TracTickets for help on using tickets.