Opened 8 years ago

Closed 2 years ago

#12511 closed bug (fixed)

Text Becomes Invisible in Div With Opacity Set <1

Reported by: achmafooma Owned by: jua
Priority: normal Milestone: R1/beta2
Component: Applications/WebPositive Version: R1/Development
Keywords: opacity div text color Cc:
Blocked By: Blocking: #12545
Platform: All

Description

In current WebPositive (in Haiku nightly), text in semi-transparent divs (opacity set below 1) can become invisible.

An example HTML file is attached. It includes two identical blocks, but with the first set to 0.95 opacity.

Text in the second block is visible (as it should be). Text in the first block SHOULD be visible (#000 on #FFF background with the whole block at 0.95 opacity), but it is not.

Attachments (5)

test.html (591 bytes ) - added by achmafooma 8 years ago.
example HTML exhibiting this bug
Bay_login.png (56.2 KB ) - added by vidrep 7 years ago.
screenshot1.png (32.1 KB ) - added by vidrep 7 years ago.
screenshot2.png (33.7 KB ) - added by vidrep 7 years ago.
screenshot3.png (524.7 KB ) - added by vidrep 5 years ago.

Download all attachments as: .zip

Change History (25)

by achmafooma, 8 years ago

Attachment: test.html added

example HTML exhibiting this bug

comment:1 by pulkomandy, 8 years ago

Owner: changed from pulkomandy to jua
Status: newassigned

comment:2 by joy, 8 years ago

Sounds like ticket 12493, but with an better description.

comment:3 by pulkomandy, 8 years ago

Milestone: R1/beta1R1

comment:4 by pulkomandy, 7 years ago

Blocking: 12493 added

comment:5 by pulkomandy, 7 years ago

Blocking: 12493 removed

What happens here:

The opacity triggers the creation of a layer for drawing in WebKit. However, we apparently don't support drawing a string "with offsets" as it is done by WebKit (AS_DRAW_STRING_WITH_OFFSETS). My guess is because support for that is still missing in BPicture.

A normal DrawString works as expected, but it doesn't exactly match glyph metrics from webkit, so the text is not exactly at the right place, which creates some other (more subtle) rendering problems. This is why the "with offset" version was added in the first place.

comment:6 by pulkomandy, 7 years ago

Blocking: 12545 added

comment:7 by vidrep, 7 years ago

I'm seeing this on this website: https://hudsonsbay.capitalone.com/#/sign-in?locale=en_CA Bay_login.png attached

Last edited 7 years ago by vidrep (previous) (diff)

by vidrep, 7 years ago

Attachment: Bay_login.png added

comment:8 by vidrep, 7 years ago

Here's another URL with the same or similar problem: https://drive.google.com/file/d/0B8n9qMefrOQJVXFobGRFOTR4RzA/view (screenshot1.png)

The download button is invisible until the mouse is hovered over it (top right) (screenshot2.png)

Last edited 7 years ago by vidrep (previous) (diff)

by vidrep, 7 years ago

Attachment: screenshot1.png added

by vidrep, 7 years ago

Attachment: screenshot2.png added

comment:9 by vidrep, 7 years ago

hrev51259 x86_gcc2h HaikuWebKit 1.6.0 Problem remains as before on this URL: https://hudsonsbay.capitalone.com/#/sign-in?locale=en_CA

by vidrep, 5 years ago

Attachment: screenshot3.png added

comment:10 by vidrep, 5 years ago

Tested with latest webkit 607.1.5. Screenshot 3.png shows the text on the Just Energy Log-in is almost invisible.

comment:11 by vidrep, 5 years ago

This issue is unchanged using current WebKit build

HaikuWebKit 1.6.7

WebKit 607.1.17

comment:12 by waddlesplash, 5 years ago

This patch should solve the issue: https://review.haiku-os.org/c/haiku/+/544

comment:13 by waddlesplash, 5 years ago

Resolution: fixed
Status: assignedclosed

Attached test file now renders properly, so it seems this was indeed fixed by that patch.

comment:14 by vidrep, 5 years ago

The problem persists on this URL: https://my.justenergy.com/

See comment: 10 above and attched screenshot for comparison. It's worse now on that page.

comment:15 by nielx, 4 years ago

Milestone: R1R1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

comment:16 by thebuck, 2 years ago

Resolution: fixed
Status: closedreopened

New testcase involving transform revives the issue.

comment:17 by nephele, 2 years ago

Please open a new ticket for that (Against kits/webkit, not webpositive), the bug with the html test case there has been fixed, so it is likely a different even if similar bug.

comment:18 by thebuck, 2 years ago

Split out transform-related issues to #17665 per nephele's request.

I think it is hard to get that Kits/Web Kit refers to WebKit/HaikuWebKit because of the space and because it is not located where the other kits are...

comment:19 by nephele, 2 years ago

It's fine to put stuff into the webpositive category if you aren't sure, this is more an organization for myself so I know what stuff to fix more on webkits side rather than webpositives UI code ;) (This is also a bit of a preperation for the webkit native api, which will probably be used by Mail, MediaPlayer, a native e-book reader etc. WebPositive is unlikely to stay the only client. Then again we might use NetSurf apis for some of this instead) Usually whatever HaikuLauncher can reproduce i put into the webkit category

comment:20 by nephele, 2 years ago

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.