Bug 119567 - LayoutTests/canvas/philip/tests/2d.text.draw.space.collapse.nonspace.html is against the spec
Summary: LayoutTests/canvas/philip/tests/2d.text.draw.space.collapse.nonspace.html is ...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Canvas (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2013-08-08 02:23 PDT by Rashmi Shyamasundar
Modified: 2013-10-29 05:16 PDT (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Rashmi Shyamasundar 2013-08-08 02:23:11 PDT
The layout test - LayoutTests/canvas/philip/tests/2d.text.draw.space.collapse.nonspace.html, is against the spec.

According to the below points in spec :-

1. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#text-preparation-algorithm 
2. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#space-character 

Only 4 space characters listed below should be replaced with U+0020
1. U+0009
2. U+000A
3. U+000C
4. U+000D

But, this test case is expecting that U+000B should also be replaced with U+0020.

Currently this test case passing on WebKit, since we are replacing U+000B with U+0020. So, both the implementation and the test case needs to be corrected.
Comment 1 Rashmi Shyamasundar 2013-08-08 02:24:19 PDT
I am trying to fix the implementation as part of patch to the bug - 

Comment 2 Rashmi Shyamasundar 2013-08-08 02:51:21 PDT
There is a bug on W3C for the same test case :-


And, the proposed patch in this W3C bug is to :-

replace the line
      "ctx.fillText('E\x0b EE', -150, 37.5);"

      "ctx.fillText('E\x0b EE', -100, 37.5);"
Comment 3 Chris Dumez 2013-08-08 03:16:25 PDT
How do other browsers (Firefox 23 / IE10) behave?
Comment 4 Chris Dumez 2013-08-08 04:40:35 PDT
(In reply to comment #3)
> How do other browsers (Firefox 23 / IE10) behave?

The test passes on Firefox 23, WebKit and Blink.

It fails on IE10 but apparently due to lack of support:
"Aborted with exception: Object doesn't support property or method 'getContext'"

So it seems Chrome / Safari / Firefox and currently in sync. I would not change our behavior despite what the specification says.
Comment 5 Rashmi Shyamasundar 2013-08-16 04:10:01 PDT
According to this draft spec - http://www.w3.org/html/wg/drafts/html/master/single-page.html#space-character , U+000B is an undefined Unicode character and its usage should result in a parse error.

Extracted from the above link :-

Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse errors. These are all control characters or permanently undefined Unicode characters (noncharacters).
Comment 6 Ian 'Hixie' Hickson 2013-08-27 16:24:59 PDT
This test seems bogus to me -- how do you know what the font will draw U+000B as?

A better test would be something like comparing these two calls:

   ctx.fillText("E \x0b E", ...
   ctx.fillText("E E", ...

...to see if the two spaces collapse into one.

There should probably also be a separate test that checks the text in:


...saying that control characters in general should be ignored...
Comment 7 Rashmi Shyamasundar 2013-10-29 05:16:59 PDT
As discussed with Mr. Christophe Dumez :-

The test passes on Chrome / Safari and Firefox. Our behavior should be in sync with others, despite what the specification says.