WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
ASSIGNED
87355
canvas/philip/tests/2d.text.draw.fontface.notinpage.html is flaky/failing because of custom font loading
https://bugs.webkit.org/show_bug.cgi?id=87355
Summary
canvas/philip/tests/2d.text.draw.fontface.notinpage.html is flaky/failing bec...
Chris Dumez
Reported
2012-05-24 01:34:22 PDT
canvas/philip/tests/2d.text.draw.fontface.notinpage.html is failing on EFL port. The problems seems be caused the loading of a custom font, which delays the drawing of the text on the canvas. As a consequence, the text is not drawn yet when the test is checking points color on the canvas.
Attachments
Patch
(7.19 KB, patch)
2012-11-26 13:55 PST
,
Chris Dumez
peter+ews
: commit-queue-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Zan Dobersek
Comment 1
2012-08-28 09:42:41 PDT
The test now also fails on the GTK platform after the memory cache started to be cleared in between test runs in
r126846
:
http://trac.webkit.org/changeset/126846
Alexey Proskuryakov
Comment 2
2012-09-14 11:38:48 PDT
This test is currently flaky on Mac, both WK1 and WK2.
Chris Dumez
Comment 3
2012-11-26 09:26:49 PST
Bug 96835
is related.
Chris Dumez
Comment 4
2012-11-26 09:36:23 PST
I'm working on a patch proposal for this. I'll hopefully upload it soon, sorry for the delay.
Chris Dumez
Comment 5
2012-11-26 13:55:33 PST
Created
attachment 176056
[details]
Patch Here is a patch proposal. I confirmed that it makes LayoutTests/canvas/philip/tests/2d.text.draw.fontface.notinpage.html pass consistently and does not seem to cause any regression. I open to suggestions if someone has a better idea to solve this.
Peter Beverloo (cr-android ews)
Comment 6
2012-11-26 14:18:56 PST
Comment on
attachment 176056
[details]
Patch
Attachment 176056
[details]
did not pass cr-android-ews (chromium-android): Output:
http://queues.webkit.org/results/14982796
WebKit Review Bot
Comment 7
2012-11-26 14:26:51 PST
Comment on
attachment 176056
[details]
Patch
Attachment 176056
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/14980928
Tony Chang
Comment 8
2012-11-26 14:29:51 PST
Does the canvas spec say what should happen when trying to draw text that hasn't loaded yet? Waiting for the font sounds wrong.
Chris Dumez
Comment 9
2012-11-26 14:58:06 PST
I took a closer look at the latest draft (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext
): "If a font is used before it is fully loaded, or if the font style source object does not have that font in scope at the time the font is to be used, then it must be treated as if it was an unknown font, falling back to another as described by the relevant CSS specifications. [CSSFONTS]" So, it seems that you are right. We apparently shouldn't wait for the font but instead fallback to another. I'm not sure this is going to help with canvas/philip/tests/2d.text.draw.fontface.notinpage.html though as it may rely on the custom font to pass (I'll need to try).
Darin Adler
Comment 10
2012-11-27 09:57:31 PST
(In reply to
comment #9
)
> We apparently shouldn't wait for the font but instead fallback to another. I'm not sure this is going to help with canvas/philip/tests/2d.text.draw.fontface.notinpage.html though as it may rely on the custom font to pass (I'll need to try).
If so, then it seems the test is flawed and requires behavior that’s not part of the spec.
Chris Dumez
Comment 11
2012-11-27 09:59:55 PST
(In reply to
comment #10
)
> (In reply to
comment #9
) > > We apparently shouldn't wait for the font but instead fallback to another. I'm not sure this is going to help with canvas/philip/tests/2d.text.draw.fontface.notinpage.html though as it may rely on the custom font to pass (I'll need to try). > > If so, then it seems the test is flawed and requires behavior that’s not part of the spec.
Yes, I agree.
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