WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
222753
[GLIB] fast/text/multi-code-unit-simple-path.html is image failing
https://bugs.webkit.org/show_bug.cgi?id=222753
Summary
[GLIB] fast/text/multi-code-unit-simple-path.html is image failing
Lauro Moura
Reported
2021-03-04 11:11:29 PST
fast/text/multi-code-unit-simple-path.html This test tries to render \x11300 and expects a mismatch with an empty document (i.e. something should be rendered). For both GTK and WPE, an empty actual.png is generated, making the expected mismatch to fail. MiniBrowser correctly renders the box around the would be glyph. Forcing WTR to dump the render tree (by removing the expected html), there is a text run for the character: layer at (0,0) size 800x600 RenderView at (0,0) size 800x600 layer at (0,0) size 800x71 RenderBlock {HTML} at (0,0) size 800x71 RenderBody {BODY} at (8,8) size 784x55 RenderBlock {DIV} at (0,0) size 784x55 RenderText {#text} at (0,1) size 37x53 text run at (0,1) width 37: "\x{D804}\x{DF00}" The same failure happens with other characters where the browsers shows the placeholder box, even from the BMP (so, unrelated to the original patch from bu221356). For example, \u1800 (Mongolian block).
Attachments
Pixel dump of "a᠀c"
(4.21 KB, image/png)
2021-03-04 11:19 PST
,
Lauro Moura
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Lauro Moura
Comment 1
2021-03-04 11:19:25 PST
Created
attachment 422262
[details]
Pixel dump of "a᠀c" Looks like the issue is WTR not drawing the placeholder box, as this dump shows for "a᠀c". The browser correctly shows the placeholder instead of the empty space. Should WTR draw the placeholder too?
Radar WebKit Bug Importer
Comment 2
2021-03-11 11:12:15 PST
<
rdar://problem/75324483
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug