Canvas: fix 21 correctness and robustness bugs in the shared Canvas2D polyfill

[bkaradzic-microsoft]

Fixes #1782.

21 Canvas2D bugs in the shared canvas polyfill. All are backend-agnostic (nanovg / polyfill level), so they affect the existing bgfx path exactly as found — I hit them while bringing up a WebGPU canvas backend, but nothing here is WebGPU-specific.

Most are "the method threw not implemented but the caller was asking for nothing", or "the paint was built from the wrong geometry". Several have to land together: 1-4 are all required before the GUI ColorPicker renders at all, and 5-8 before a gradient-stroked GUI control renders at all.

Correctness

#	Bug
1	ImageData.data returned a fresh copy on every access, so getImageData → mutate → putImageData silently no-op'd. It is also now the specified Uint8ClampedArray; a plain Uint8Array wrapped data[i] = v + 40 modulo 256, turning bright pixels dark
2	clip() suppressed beginPath() for every later draw, so each fill repainted the union of every rect since the clip
3	3-arg drawImage(img, dx, dy) anchored the pattern at (0,0) while drawing the rect at (dx,dy), so it drew nothing at any non-zero offset
4	Gradient paint was built from the shape being filled, not the gradient — every gradient came out horizontal, anchored at the canvas origin, with (x0,y0)→(x1,y1) discarded
5	strokeStyle accepted only a color string; a gradient threw TypeError: A string was expected and took the whole scene down (GUI Line, Button border)
6	Radial gradients discarded the inner circle, so every one came out concentric with r0 == 0. Now solves the real two-circle equation. The tangent case (leading coefficient vanishes → linear solve) needs its own branch and is not exotic — the repro's createRadialGradient(100,100,150, 250,100,300) lands there
7	Color stops were interpolated in straight alpha, so #ff0000ff → #00000000 faded through maroon to black. Now premultiplied as specified
8	fill() never bound the fill style, using whatever color nanovg happened to hold — never a gradient. Every path-filled control (Ellipse, Button background, Slider) filled solid white
9	createImageData was missing entirely
10	Path2D was registered only on _native, not as a global, so AbstractEngine.createCanvasPath2D threw ReferenceError on every engine except ThinNativeEngine
11	loadTTF failures surfaced as a bare Error: Invalid argument, naming neither method nor argument. Now descriptive, and any ArrayBuffer view is accepted — so the usual real cause, Tools.LoadFileAsync(url) without useArrayBuffer, is named directly
12	putImageData was an unconditional throw. Now writes through a transient nanovg image under nvgSave/nvgReset with NVG_COPY, so it correctly ignores transform, clip, globalAlpha, compositing, shadows and filters and replaces rather than blends
13	setLineDash threw — and GUI Line/MultiLine call it every render with _dash defaulting to [], so any scene with a GUI line died on an empty dash list asking for nothing. Empty now means "solid", which is what we already draw
14	The color regex matched components as 1-3 digit integers, so the very common rgba(0, 0, 0, 0.5) failed to parse. Now generic CSS numbers with optional %, plus the whitespace-separated and / alpha forms and hsl()/hsla() — see the behaviour change below
15	All four shadow attributes threw from both getter and setter — and GUI resets shadowBlur/shadowOffset* to 0 right after drawing, so the throw hit the reset path too and any shadowed control failed outright. nanovg has no shadow primitive, but these are ordinary state attributes, so they are stored and reported
16	save()/restore() snapshotted only fillStyle/strokeStyle, but the wrapper mirrors everything it reprojects or that nanovg cannot report back — so lineCap, lineJoin, lineWidth, miterLimit, the dash list, filter, direction, letterSpacing, globalAlpha and the shadow attributes were never restored. The getters reported the post-save() value forever, and the shadow attributes, re-applied from the mirror on every draw, actually rendered wrong. All fifteen fields are now snapshotted
17	Coincident color stops were dropped — std::map::insert() discarded the second stop at an already-present offset, which is exactly how the spec encodes a hard transition, so a stripe pattern came out as a smooth fade. Now a std::multimap
18	setLineDash() cleared the list before validating, so setLineDash([-1]) after setLineDash([5,10]) left getLineDash() returning []

Two smaller gradient bugs were fixed alongside 4-8: the ramp sample buffer was uninitialized (samples outside the stop range read stack garbage), and gradientSpan divided by zero when two stops shared an offset.

Robustness

Three crash classes found by the Copilot review, all reachable from ordinary script rather than only from a misbehaving embedder:

#	Bug
19	fillStyle = "rgb(999…999, 0, 0)", font = "18e999px Arial" and letterSpacing = "999…999px" made std::stof/std::stoi throw std::out_of_range. That is not a Napi::Error, so node-addon-api's wrapper did not catch it and it unwound out of the N-API boundary and terminated the process. Now strtof/strtol, with infinities folded to finite extremes so the existing clamps stay well defined (nvgHSLA takes fmodf of the hue, and fmodf(inf, 1) is NaN)
20	A gradient outliving its context: UpdateCache() dereferenced context.lock() three times unchecked, so the guard in Paint() ran after the crash
21	putImageData(img, 0, 0, 0, 0, -2147483648, 1) normalized negative dirty extents in int32_t, making dirtyX += dirtyWidth and -dirtyWidth signed overflow on caller-controlled input. Now int64_t, saturating back after clipping

19 is confirmed by experiment, not inspection: built without the fix, the unit test binary stops dead inside the Canvas2D suite with [Uncaught Error] Unknown failure and exit 1, taking the remaining ~20 tests with it. The pre-existing font guard covered only std::invalid_argument (the "normal" keyword), so out_of_range still went through.

One intentional behaviour change — please look at this closely

The parseColor unit test asserted rgba(16,32,48,64) → alpha 0x40, i.e. that alpha is a 0-255 channel like r/g/b. CSS Color defines alpha as 0-1 (or a percentage), so a browser clamps 64 to 1 and paints that colour opaque.

That reading was not a deliberate extension — the old regex matched all four components as 1-3 digit integers and ran std::stoi over them, so alpha simply inherited the channel treatment, and the test was written to describe what the implementation happened to do (it arrived with the impl in #1051). It is also the same root cause as bug 14: under a 0-255 alpha, rgba(0, 0, 0, 0.5) truncates to 0 and the colour vanishes. Alpha cannot be both, so the test now follows CSS, extended to cover fractional and percentage alpha, the / alpha form, whitespace-separated and percentage components, and hsl()/hsla(). All ten malformed-input cases still throw.

Deliberate limitations

• Non-rectangular clip() is approximated. nanovg's scissor is rectangle-only and no stencil path is available, so the choice is between approximating and throwing; this keeps the rectangular case exact and degrades the other rather than failing the scene.
• putImageData() clobbers the current path — as do fillRect, clearRect, drawImage and Path2D playback, none of which may touch it per spec. nanovg offers no local fix, since nvgSave/nvgRestore only push and pop NVGstate while nvgBeginPath clears ctx->ncommands and the path cache. A real fix means journaling the path wrapper-side and replaying it; self-contained, and better as a follow-up.

Validation

Full Playground validation sweep 304/304 PASS, no regressions; JavaScript.All unit tests 36/36.

Three previously-excluded tests are re-enabled and now pass inside the default 2.5% budget:

Test	Before	After	Needs
GUI Gradient Linear (#XCPP9Y#17227)	TypeError — never rendered	1.14%	5, then 8
GUI Gradient Radial (#4Z7EK3)	23.6%	0.62%	6 (tangent case)
GUI Gradient Linear with transparency (#PFK1Z5)	33.8%	pixel-exact	7

The GUI test went 13.5% → 3.9% (allowed 4%) across bugs 1-4 — 13.5% → 8.2% (clip) → 6.4% (drawImage origin) → 3.9% (gradients) — because its ColorPicker builds its wheel via getImageData + mutate + putImageData (1), composites it with a 3-arg drawImage at a non-zero offset (3), draws it and its saturation square under one clip() (2), and paints that square with two overlaid linear gradients (4). Nine further tests newly pass across the same four fixes.

Bugs 10 and 11 are test-neutral and were verified directly, and new Canvas2D unit tests cover the contract that used to throw: both style round-trips, a CanvasGradient as fillStyle and as strokeStyle, a radial gradient from two independent circles, save/restore of a gradient strokeStyle and of all fifteen state fields, dash retention on a rejected argument, coincident stops, and three regressions for the out-of-range parse crashes.

One implementation note: DataView is read through its buffer/byteOffset/byteLength properties rather than Napi::DataView, because Chakra's Node-API backs napi_get_dataview_info with JsGetExternalData, which only succeeds for natively created DataViews — a JS-constructed one fails with napi_invalid_arg even though napi_is_dataview returns true. That shim inconsistency is a separate JsRuntimeHost issue; this change just avoids depending on it.

[Copilot]

Pull request overview

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Fixes multiple Canvas2D correctness issues in the shared canvas polyfill (ImageData semantics, clipping/path behavior, drawImage anchoring, gradient geometry, and missing createImageData).

Changes:

• Make ImageData.data a stable, spec-correct clamped typed array instead of returning a fresh copy each access.
• Fix path handling under clip() and correct 3-arg drawImage() pattern anchoring.
• Implement gradient paints based on gradient geometry (plus ramp baking fixes) and add createImageData() overloads.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
Polyfills/Canvas/Source/ImageData.h	Store and reuse a persistent JS typed array for ImageData.data.
Polyfills/Canvas/Source/ImageData.cpp	Allocate clamped backing array once, read pixels into it, and return it unchanged.
Polyfills/Canvas/Source/Gradient.h	Add CanvasGradient::Paint() API to produce geometry-correct NanoVG paint.
Polyfills/Canvas/Source/Gradient.cpp	Fix ramp baking edge cases and implement paint generation for linear/radial gradients.
Polyfills/Canvas/Source/Context.h	Add createImageData() and simplify BindFillStyle signature.
Polyfills/Canvas/Source/Context.cpp	Register/implement createImageData(), fix clip/path behavior, fix drawImage anchoring, use gradient->Paint().

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 3 comments.

Suppressed comments (12)

Polyfills/Canvas/Source/Context.cpp:922

• putImageData() must not modify the current path, but the implementation calls nvgBeginPath()/nvgRect() and then explicitly records that the path is now the upload rectangle. A path built before putImageData() is consequently lost, and a following stroke()/fill() targets the wrong geometry. Render the upload without replacing the user path, or preserve/replay the path around this internal draw.

        // The path now holds just this rect, so clear the non-rect flag: a stale `true` left over
        // from an earlier arc/curve would make a subsequent clip() take the emulated path branch.
        m_pathHasNonRect = false;

Polyfills/Canvas/Source/Context.h:122

• These shadow attributes are also Canvas2D drawing state, but they are not included in SavedStyle; restore() only rewinds fill/stroke. A shadow value assigned after save() therefore survives restore(), contradicting the round-trip/state behavior described in the PR. Store and restore all four shadow fields.

        // Shadow attributes from shadowColor/shadowBlur/shadowOffsetX/shadowOffsetY.
        // Retained only so the getters round-trip; nanovg has no shadow primitive,
        // so nothing is ever drawn from them. Defaults are the spec's.
        std::string m_shadowColor{"rgba(0, 0, 0, 0)"};
        double m_shadowBlur{0.0};

Polyfills/Canvas/Source/Gradient.cpp:388

• This still maps the old concentric texture onto (x1, y1, r1). RadialGradientStops() fixes its focal point at the texture center (fxp/fyp = 0) and never uses x0, y0, or r0, so non-concentric and nonzero-inner-radius gradients—including the tangent case named in the PR—remain incorrect. The baked field must evaluate the two-circle equation before this paint is mapped.

        // The radial ramp is baked into a square image whose inscribed circle is the r1
        // isoline, so map that image onto the bounding box of the outer circle.
        const float radius = std::max(r1, 1e-4f);
        return nvgImagePattern(*nvg, x1 - radius, y1 - radius, 2.f * radius, 2.f * radius, 0.f, cachedImage, 1.f);

Polyfills/Canvas/Source/Gradient.cpp:167

• Zero-initializing the ramp does not implement the claimed premultiplied-alpha interpolation. gradientSpan() still interpolates raw r/g/b/a independently at lines 53-60, and lerpColor() does the same at lines 194-200, so transparent linear and radial stops still fade through dark straight-alpha colors. Premultiply RGB before interpolation and unpremultiply the baked sample afterward in both paths.

        // Zero-initialize: the spans below only cover the range the stops span, so any
        // sample left untouched would otherwise be read from uninitialized stack memory.
        uint32_t data[GRADIENT_SAMPLES_L]{};

Polyfills/Canvas/Source/Gradient.cpp:51

• This guard cannot handle coincident color stops because colors is a std::map<float, NVGcolor> and AddColorStop() uses insert; the second stop at an identical offset is discarded before gradientSpan() runs. Hard transitions at duplicate offsets therefore remain wrong. Preserve duplicate stops with ordered sequence/multimap storage and process them in insertion order.

        // Coincident stops produce an empty span; the per-sample deltas below would divide
        // by zero and write NaNs into the ramp.
        if (e <= s)
        {
            return;

Polyfills/Canvas/Source/Context.cpp:159

• The new binder is still not called by Context::Fill() (lines 266-281), which proceeds directly to nvgFill(). Assigning a gradient and then calling fill() therefore continues to use stale NanoVG paint, leaving the path-fill correctness fix described by the PR unimplemented. Bind the current fill style after any PlayPath2D() call and before nvgFill().

    void Context::BindFillStyle(const Napi::CallbackInfo& info)

Polyfills/Canvas/Source/Context.h:158

• Only a fill-style binder is introduced. m_strokeStyle/SavedStyle::strokeStyle remain strings, SetStrokeStyle() still unconditionally casts to Napi::String, and stroke, strokeRect, and strokeText never bind a gradient paint. Thus the PR's core CanvasGradient stroke support still throws on assignment. Add the matching stroke variant/binder and invoke it for every stroke operation.

        void BindFillStyle(const Napi::CallbackInfo& info);

Polyfills/Canvas/Source/Context.cpp:448

• Leaving the clip path current is not clipping: fillRect() appends its rectangle and fills the union of that rectangle and the clip path, while clearRect() and drawImage() call nvgBeginPath() and ignore this flag entirely. Non-rectangular clips therefore either paint the clip shape or are not applied. Use an actual clip mask/stencil implementation (or explicitly keep this unsupported) rather than treating the clip path as draw geometry.

This issue also appears on line 920 of the same file.

        // A non-rectangular clip path cannot be expressed as a scissor rectangle.
        // Emulate it by leaving the path current so the next fill draws it, and
        // leave any enclosing scissor untouched rather than clipping to a
        // rectangle this path never described.
        if (m_pathHasNonRect)
        {
            m_isClipped = true;
            return;

Polyfills/Canvas/Source/Context.cpp:1388

• The comment says an invalid dash list retains the previous value, but m_lineDash is cleared before validation and cleared again here. For example, after [5, 10], setLineDash([-1]) incorrectly changes getLineDash() to []. Parse into a temporary vector and assign it only after every segment validates.

                    // Per spec, a list containing a non-finite or negative value
                    // is ignored entirely and the previous list is retained; a
                    // non-numeric entry cannot be interpreted, so ignore it too.
                    m_lineDash.clear();
                    return;

Polyfills/Canvas/Source/Context.cpp:1400

• Canvas2D duplicates an odd-length dash sequence, so setLineDash([5]) must make getLineDash() return [5, 5]. The current code stores and returns only [5]. Duplicate the parsed sequence when its length is odd.

                m_lineDash.push_back(value);
            }
        }

Polyfills/Canvas/Source/Context.h:116

• m_lineDash is new wrapper-side canvas state, but SavedStyle still contains only fill/stroke styles. Consequently save(); setLineDash(...); restore(); getLineDash() does not restore the saved pattern as Canvas2D requires. Include the dash vector in the state pushed and restored alongside these fields.

This issue also appears on line 118 of the same file.

        // Dash pattern from setLineDash. Retained only so getLineDash() round-trips;
        // strokes are always drawn solid (nanovg has no dashed stroke).
        std::vector<double> m_lineDash{};

Polyfills/Canvas/Source/Canvas.cpp:77

• Buffer validation is still skipped when the font name already exists, because GetFontDataArgument() is only called inside this conditional. After one successful load, Canvas.loadTTF(name) or Canvas.loadTTF(name, "text") silently succeeds despite the PR's stated arity/type validation. Validate and extract argument 2 before the duplicate-name early-out, then discard the extracted bytes when retaining the existing font is intentional.

        if (fontsInfos.find(fontName) == fontsInfos.end())
        {
            fontsInfos[fontName] = GetFontDataArgument(info, 1, "Canvas.loadTTF");

[bkaradzic-microsoft]

You're right, and thanks for catching it — that was a genuine miss on my part, not a stale view on your end.

canvas-shared-fixes was sitting two commits ahead of the remote locally, so 99ff0b8b (gradient semantics) and 7bd4ae14 (the putImageData / std::stof / null-context hardening) never made it to the PR. The branch is now pushed and the head is 7bd4ae14; CI is re-running.

The part worth flagging: as you say, the review threads were already resolved, so the PR read as clean and green while the code being described wasn't actually on it. That's the bad failure mode here — the green checkmark was real, it just wasn't covering the fixes under discussion. I've re-verified against the pushed tree that each resolved thread now corresponds to code that's actually there:

• Colors.h — std::stof replaced with strtof, with the non-finite results folded back to finite extremes so the downstream clamps (and nvgHSLA's fmodf on hue) stay well defined.
• Context.cpp putImageData — negative-extent normalization moved into int64_t, so negating INT32_MIN and summing two INT32_MINs are no longer signed overflow.
• Gradient.cpp — context.lock() is locked once and checked for both a null shared_ptr and a null underlying context before any dereference, including on the UpdateCache() path that previously dereferenced it internally before the check.

I also confirmed the branch still merges cleanly onto current master — config.json is touched by both this branch and #1830, but it auto-merges without conflict.

Sorry for the round trip. Will wait for CI to come back green before asking for another look.

[bkaradzic-microsoft]

CI is back green on 7bd4ae14 — 34/34, no failures. Ready for another look whenever you have time, @bghgary.

[matthargett]

Thanks for closing these conformance gaps! If we are consistently beating the 2.5% threshold of incorrect pixels, I'd recommend lowering it to tighten things up a bit now that so much of the screenshot testing stability and accuracy has made such huge strides.

[bkaradzic-microsoft]

Thanks! I agree with the direction, so I pulled the actual numbers rather than guess at the headroom.

Data is from this PR's green CI run (7bd4ae14), scraped from the Pixel difference: lines the harness logs per test. Validation runs on the Win32_x64_*_D3D11 jobs, and 254 of the comparisons use the default 2.5% (the other 12 tests in config.json already carry explicit higher errorRatio overrides, 4%–35%; nothing currently overrides downward).

Distribution on the 2.5% default

p50	p75	p90	p95	p99	max
0.352%	0.709%	1.134%	1.428%	1.846%	2.249%

So the median has a ~7x margin, but the worst test sits at 2.249% — only 0.25pp under the limit. Lowering the global default is therefore not quite free:

new default	tests that would start failing
2.0%	2
1.5%	8
1.0%	33
0.5%	94

The good news is that these numbers are extremely stable, which is really the property that matters for tightening a threshold. Across two independent CI runs on different commits (bd3e3e27 → 7bd4ae14): p50 0.349% → 0.352%, p90 1.116% → 1.134%, p99 identical at 1.846%, max identical at 2.249%. And within a single run the three JS-engine jobs (Chakra / QuickJS / V8) produce byte-identical distributions — same n, same p50/p90/max, same counts over every candidate threshold. The rendering is deterministic; the 2.5% isn't absorbing run-to-run noise, it's absorbing a small number of genuinely-large stable diffs.

That means a tightening is low-risk and won't introduce flakiness — it just has to be paired with per-test overrides for the tail, exactly the mechanism config.json already uses in the other direction. Concretely I'd suggest default 1.5% plus explicit overrides on the 8 tests above it, which tightens 246 of 254 tests by 40% while leaving the known-bad ones documented and visible instead of hidden under a blanket allowance.

Two caveats worth stating: this is Win32 D3D11 only (D3D12 CI doesn't run the pixel comparison today — relevant to #1671), and the per-channel threshold of 25 is arguably the blunter knob of the two, since it's what lets a pixel be off by up to 25/255 per channel before it's even counted.

I'd rather not fold this into this PR though — it's repo-wide test policy and would churn config.json for 8 unrelated tests, whereas this PR is scoped to the Canvas polyfill. Happy to do it as a follow-up PR right after this lands, with the same measurements attached. Sound good?

[bkaradzic-microsoft]

Pushed two more commits (8bbf33bc, bd40ea28) fixing three further issues, and triaged the twelve comments in the collapsed Suppressed comments block of the Copilot review — those don't create review threads, so they weren't visible in the resolved/unresolved list and I'd missed them until now.

Most of that block was generated against bd3e3e27, before the last two pushes, so a good part of it describes code that is no longer there. Breakdown:

Fixed in this push

SavedStyle didn't include the shadow attributes. Correct, and worse than reported. nvgRestore() rewinds nanovg's copy of the state, but the wrapper keeps its own C++ mirrors of everything it has to reproject or that nanovg can't report back, and SavedStyle only snapshotted fillStyle/strokeStyle. So lineCap, lineJoin, lineWidth, miterLimit, the dash list, filter, direction, letterSpacing and globalAlpha had the same bug — the getters reported the post-save() value forever after, and the shadow attributes, which are re-applied from the mirror on every draw, actually rendered wrong. SavedStyle now snapshots all fifteen fields.

Coincident color stops were dropped. Correct — std::map + insert() silently discarded the second stop at an offset already present, which is exactly how the spec encodes a hard transition, so a stripe pattern came out as a smooth fade. Now a std::multimap. Both consumers only iterate in sorted order into a vector, so it's a drop-in, and the existing zero-width-span guard at Gradient.cpp:51 turns the duplicate offset into the required hard edge.

setLineDash() didn't retain the previous list on a rejected argument. Correct, and the code contradicted its own comment: m_lineDash was cleared before validation, so after setLineDash([5, 10]), setLineDash([-1]) left getLineDash() returning [] instead of [5, 10]. Now parsed into a temporary and committed only once every segment validates.

Three unit tests cover the state round-trip and the dash retention; a fourth covers the duplicate stops. 36/36 pass locally.

Already fixed in 99ff0b8b/7bd4ae14 — these were generated against the older head

• "Fill() never calls the new binder" / "only a fill-style binder is introduced; stroke still throws" — both BindFillStyle and BindStrokeStyle exist and are called from all six draw sites (Context.cpp:231, 329, 535, 626, 727, 1521), and m_fillStyle/m_strokeStyle are both std::variant<std::string, CanvasGradient*>, not strings.
• "premultiplied-alpha interpolation isn't actually implemented" — it is, on both paths: gradientSpan() premultiplies at Gradient.cpp:75-76 and unpremultiplies the baked sample at :88, and lerpColor() does the same at :226-227 and :232.
• "the radial paint still ignores x0, y0, r0" — it doesn't; RadialGradientStops() calls solveRadialOffset() (:362), which solves the two-circle equation over all six parameters. The image is still mapped onto the outer circle's bounding box, but that's the correct place to put it now that the ramp is baked per-pixel rather than being a concentric texture.

Known limitations, unchanged and deliberate

Non-rectangular clip(). Flagged as "not clipping" — that's fair, and it's called out as such in the PR description. nanovg's scissor is rectangle-only and there's no stencil path available here, so the choice is between an approximation and throwing. This keeps the rectangular case exact and degrades the non-rectangular one instead of failing the scene.

putImageData() clobbers the current path. Correct, and I'd rather not fix it in this PR. It isn't specific to putImageData — fillRect(), clearRect(), drawImage() and Path2D playback all call nvgBeginPath(), and per spec none of them may touch the current path. nanovg offers no way to fix it locally: nvgSave/nvgRestore only push and pop NVGstate, while nvgBeginPath clears ctx->ncommands and the path cache, which aren't part of that state. A real fix means journaling the current path wrapper-side and replaying it after each of those operations — the Path2DCommand machinery in Path2D.h is the obvious basis for it, but it means routing every path method on Context through the journal. That's a self-contained change and I'd prefer it as a follow-up rather than growing this PR further; happy to open an issue to track it.

CI was 34/34 green on the previous head; I'll confirm it stays green on bd40ea28.