Fix WPT test failures induced by switching 2D canvas rendering backend to Raqote

[pylbrecht]

#24470 left over some failing tests, which need to be addressed.

Relevant tests: tests/wpt/web-platform-tests/2dcontext/

[pylbrecht]

Tests using stroke() may require a fix on raqote's side. (#24470 (comment), #24470 (comment))

[pylbrecht]

Just a quick update to show that I'm alive: I've been on vacation for the past week and will continue working on this by Monday. My fiancee is going on vacation for two weeks then, so I got some extra time on my hands!

[pylbrecht]

@jrmuizel, any news on the stroke() issue?

[jrmuizel]

@pylbrecht nope, I haven't had a chance to complete my research on the issue. The problem is tracked upstream here: jrmuizel/raqote#96

[pylbrecht]

Unfortunately university deadlines combined with frustrating hours in the lab ate up all the extra time I planned on using for contributing this week. I hope the debugging gods show mercy tomorrow, so I can fix some wpt tests next week.

[pylbrecht]

While inspecting https://dxr.mozilla.org/servo/source/tests/wpt/web-platform-tests/2dcontext/path-objects/2d.path.rect.end.1.html, I came across something, I don't quite understand.
@jrmuizel, can you shed some light on why the image created with raqote looks like this?

expected: https://codepen.io/pylbrecht/pen/RwNJyWE

actual:

let mut dt = DrawTarget::new(300, 300);
let mut pb = PathBuilder::new();
pb.rect(0., 0., 100., 50.);
dt.fill(
    &pb.finish(),
    &Source::Solid(SolidSource::from_unpremultiplied_argb(255, 255, 0, 0)),
    &DrawOptions::new(),
    );
                                                                            
let mut pb = PathBuilder::new();
pb.rect(200., 100., 400., 1000.);
pb.line_to(-2000., -1000.);
dt.stroke(
    &pb.finish(),
    &Source::Solid(SolidSource::from_unpremultiplied_argb(255, 0, 255, 0)),
    &StrokeStyle {
        width: 100.,
        cap: LineCap::Butt,
        join: LineJoin::Miter,
        miter_limit: 10.,
        dash_array: Vec::new(),
        dash_offset: 0.,
    },
    &DrawOptions::new(),
    );
                                                                            
dt.write_png("example.png");

// edit:
Moving to the rectangle's starting point after drawing it seems to lead in the right direction, but it's still not quite there:

let mut dt = DrawTarget::new(300, 300);
let mut pb = PathBuilder::new();
pb.rect(0., 0., 100., 50.);
dt.fill(
    &pb.finish(),
    &Source::Solid(SolidSource::from_unpremultiplied_argb(255, 255, 0, 0)),
    &DrawOptions::new(),
    );
                                                                            
let mut pb = PathBuilder::new();
pb.rect(200., 100., 400., 1000.);
pb.move_to(200., 100.);
pb.line_to(-2000., -1000.);
dt.stroke(
    &pb.finish(),
    &Source::Solid(SolidSource::from_unpremultiplied_argb(255, 0, 255, 0)),
    &StrokeStyle {
        width: 100.,
        cap: LineCap::Butt,
        join: LineJoin::Miter,
        miter_limit: 10.,
        dash_array: Vec::new(),
        dash_offset: 0.,
    },
    &DrawOptions::new(),
    );
                                                                            
dt.write_png("example.png");

[jrmuizel]

This is a bug in raqote. I'm working on a fix.

[jrmuizel]

Fixed in jrmuizel/raqote@0cad3c3

[pylbrecht]

I'm currently investigating 2dcontext/pixel-manipulation/2d.imageData.create2.nonfinite.html.ini and somehow the expected TypeError is not thrown.
Through inspecting the CreateImageData() call I found that a JS Infinity is converted into a Rust 0.
The spec says that an IndexSizeError should be thrown if sh == 0 || sw == 0.
Since Infinity is converted to 0, there is no way differentiating these two cases (TypeError vs. IndexSizeError).

I have a little hunch that the expected TypeError should be thrown while converting the JS value to a Rust value.

I tried to figure out where the conversion is performed, but I couldn't point my finger on the exact place in the code. I wasn't even sure if the area I was looking around in was the right one. I read the script::dom::bindings docs and also found script::dom::bindings::conversions, but I felt a little overwhelmed looking at the code with some of it being auto-generated.

@jdm, I need a little guidance on this one. Can you help me out?

[jdm]

Yep! Since the arguments are long values, the spec for conversion comes from webidl. The conversion from JS values to the Rust arguments starts in the generated code in unsafe extern fn createImageData(cx: SafeJSContext, _obj: HandleObject, this: *const CanvasRenderingContext2D, args: *const JSJitMethodCallArgs) -> bool { in CanvasRenderingContext2DBindings.rs, which invokes FromJSValConvertible::from_jsval with a i32 output value. That comes from this code, which invokes this code, and this code is where we start to actually make decisions about values. I suspect we end up invoking https://github.com/servo/mozjs/blob/b2f83932fe9d361face14efd03f2465b9262e687/mozjs/js/src/jsnum.cpp#L1812-L1825.

Overall, I have a suspicion that we're not actually implementing https://heycam.github.io/webidl/#abstract-opdef-converttoint anywhere.

[jdm]

Then again, at first glance it's not entirely clear to me why this test expects a TypeError, since https://html.spec.whatwg.org/multipage/canvas.html#canvasimagedata doesn't use [EnforceRange]. Yet https://wpt.fyi/results/2dcontext/pixel-manipulation/2d.imageData.create2.nonfinite.html?label=master&label=experimental&aligned&q=create2.nonfinite shows that all other browsers pass this.

[jdm]

Firefox's generated code has this interesting snippet: https://searchfox.org/mozilla-central/source/__GENERATED__/dom/bindings/CanvasRenderingContext2DBinding.cpp#4136-4143

[jdm]

Huh - Firefox's WebIDL doesn't match the specification, which explains the difference: https://searchfox.org/mozilla-central/rev/c79c0d65a183d9d38676855f455a5c6a7f7dadd3/dom/webidl/CanvasRenderingContext2D.webidl#266-268

[jdm]

And that change was made in 2017: whatwg/html#2452 :(

[jdm]

I filed whatwg/html#5336 about changing the spec.

[pylbrecht]

On @jdm's advice I will stall working on any test cases related to this until whatwg/html#5336 is resolved.

[pylbrecht]

2dcontext/fill-and-stroke-styles/2d.pattern.image.nosrc.html fails on this assertion:

var img = document.createElementNS("http://www.w3.org/2000/svg", "image");
_assertSame(ctx.createPattern(img, 'repeat'), null, "ctx.createPattern(img, 'repeat')", "null");

with the output of:

  ▶ Unexpected subtest result in /2dcontext/fill-and-stroke-styles/2d.pattern.image.nosrc.html:
  │ FAIL [expected PASS] Canvas test: 2d.pattern.image.nosrc
  │   → argument could not be converted to any of: HTMLImageElement, HTMLCanvasElement, OffscreenCanvas, CSSStyleValue
  │
  │ @http://web-platform.test:8000/2dcontext/fill-and-stroke-styles/2d.pattern.image.nosrc.html:25:17
  │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1926:25
  │ _addTest/</<@http://web-platform.test:8000/2dcontext/resources/canvas-tests.js:66:15
  │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1926:25
  └ _addTest/<@http://web-platform.test:8000/2dcontext/resources/canvas-tests.js:63:11

The auto-generated code UnionTypes.rs shows that SVGImageElement is not considered for the conversion:

#[derive(JSTraceable)]
pub enum HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue {
    HTMLImageElement(DomRoot<HTMLImageElement>),
    HTMLCanvasElement(DomRoot<HTMLCanvasElement>),
    OffscreenCanvas(DomRoot<OffscreenCanvas>),
    CSSStyleValue(DomRoot<CSSStyleValue>),
}

...

impl FromJSValConvertible for HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue {
    type Config = ();
    unsafe fn from_jsval(cx: *mut JSContext,
                         value: HandleValue,
                         _option: ())
                         -> Result<ConversionResult<HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue>, ()> {
        if value.get().is_object() {
            match HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::TryConvertToHTMLImageElement(SafeJSContext::from_ptr(cx), value) {
                Err(_) => return Err(()),
                Ok(Some(value)) => return Ok(ConversionResult::Success(HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::HTMLImageElement(value))),
                Ok(None) => (),
            }
            match HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::TryConvertToHTMLCanvasElement(SafeJSContext::from_ptr(cx), value) {
                Err(_) => return Err(()),
                Ok(Some(value)) => return Ok(ConversionResult::Success(HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::HTMLCanvasElement(value))),
                Ok(None) => (),
            }
            match HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::TryConvertToOffscreenCanvas(SafeJSContext::from_ptr(cx), value) {
                Err(_) => return Err(()),
                Ok(Some(value)) => return Ok(ConversionResult::Success(HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::OffscreenCanvas(value))),
                Ok(None) => (),
            }
            match HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::TryConvertToCSSStyleValue(SafeJSContext::from_ptr(cx), value) {
                Err(_) => return Err(()),
                Ok(Some(value)) => return Ok(ConversionResult::Success(HTMLOrSVGImageElementOrHTMLCanvasElementOrOffscreenCanvasOrCSSStyleValue::CSSStyleValue(value))),
                Ok(None) => (),
            }

        }

        Ok(ConversionResult::Failure("argument could not be converted to any of: HTMLImageElement, HTMLCanvasElement, OffscreenCanvas, CSSStyleValue".into()))
    }
}

Is SVGImageElement implemented at all (haven't found a filed issue either)? I only found SVGGraphicsElement.

// edit:
I see there are two specifications linked for SVGImageElement. Still, what would be the course of action here?

[jdm]

There is no SVG implementation in Servo right now. It's not worth investigating any failures that involve SVG elements.

[pylbrecht]

Alright, then they'll go on the exclude list (for now). Thanks!

[pylbrecht]

Here's a list with tests, which are ignored for now due to various reasons. I will update the list on the go.

Not implemented yet:

CanvasRenderingContext2D.drawFocusIfNeeded()

• 2dcontext/drawing-paths-to-the-canvas/drawFocusIfNeeded_001.html
• 2dcontext/drawing-paths-to-the-canvas/drawFocusIfNeeded_002.html
• 2dcontext/drawing-paths-to-the-canvas/drawFocusIfNeeded_003.html
• 2dcontext/drawing-paths-to-the-canvas/drawFocusIfNeeded_004.html
• 2dcontext/drawing-paths-to-the-canvas/drawFocusIfNeeded_005.html

SVG image handling

• 2dcontext/fill-and-stroke-styles/2d.pattern.image.zeroheight.html
• 2dcontext/fill-and-stroke-styles/2d.pattern.image.zerowidth.html
• 2dcontext/fill-and-stroke-styles/2d.pattern.image.nonexistent-but-loading.html
• 2dcontext/drawing-images-to-the-canvas/2d.drawImage.zerosource.image.html
• 2dcontext/fill-and-stroke-styles/2d.pattern.image.nosrc.html

Depends on jrmuizel/raqote#96

• 2dcontext/path-objects/2d.path.arc.scale.2.html
• 2dcontext/path-objects/2d.path.arc.selfintersect.1.html
• 2dcontext/path-objects/2d.path.arc.selfintersect.2.html
• 2dcontext/path-objects/2d.path.arc.shape.3.html
• 2dcontext/path-objects/2d.path.arc.shape.4.html

Depends on jrmuizel/raqote#118 (fixed)

• 2dcontext/fill-and-stroke-styles/2d.gradient.radial.touch1.html
• 2dcontext/fill-and-stroke-styles/2d.gradient.radial.touch2.html
• 2dcontext/fill-and-stroke-styles/2d.gradient.radial.touch3.html

Unknown

• 2dcontext/fill-and-stroke-styles/2d.gradient.radial.outside2.html
• 2dcontext/fill-and-stroke-styles/2d.gradient.radial.outside3.html

Depends on raqote implementing shadows (jrmuizel/raqote#83)

• 2dcontext/drawing-rectangles-to-the-canvas/2d.fillRect.shadow.html
• 2dcontext/drawing-rectangles-to-the-canvas/2d.strokeRect.shadow.html
• 2dcontext/shadows/

Miscellaneous

• 2dcontext/fill-and-stroke-styles/2d.pattern.image.broken.html (#25940 (comment))
• 2dcontext/drawing-images-to-the-canvas/2d.drawImage.broken.html (#25940 (comment))