Canvas: reject foreign objects instead of unwrapping them as a Path2D or gradient by bkaradzic-microsoft · Pull Request #1844 · BabylonJS/BabylonNative

bkaradzic-microsoft · 2026-08-20T00:41:07Z

Follow-up to #1824, as agreed in review.

ObjectWrap::Unwrap does no type checking -- it reinterprets the object's internal pointer as the target type. Four call sites reached it without establishing that the object was actually a NativeCanvasPath2D:

call	gate before	hole
`ctx.stroke(x)`	none	`ctx.stroke("x")` cast a string straight into `Unwrap`
`ctx.fill(x)`	`IsObject()`	`ctx.fill({})` still got through
`new Path2D(x)`	`IsObject()`	same hole
`path.addPath(x)`	none, and no arity check	`addPath()` unwrapped a missing argument

stroke was the worst, as noted in review:

// before
const NativeCanvasPath2D* path = info.Length() == 1
    ? NativeCanvasPath2D::Unwrap(info[0].As<Napi::Object>()) : nullptr;

Change

The check has to be one script cannot forge. instanceof is not, because a prototype is assignable:

Object.setPrototypeOf(gradient, Path2D.prototype);
ctx.fill(gradient);            // unwrapped a CanvasGradient as a path -> 0xC0000005
ctx.fillStyle = spoofedPath;   // stored, then Unwrap(...)->Paint() -> 0xC0000005

Both directions are an access violation, reproduced on Win32 D3D11. Object.create(Path2D.prototype) gets through the same way while having no native wrap behind it at all. CanvasGradient had the identical gate, so it is fixed here too.

napi_type_tag_object would be the idiomatic answer, but only the V8 port implements it in this tree -- Chakra, JavaScriptCore and QuickJS do not. A brand property is forgeable even under a symbol, since Object.getOwnPropertySymbols hands the symbol to script.

So the authority lives in C++, where script cannot reach it. NativeInstanceRegistry<T> records the address of every live instance, and a candidate is accepted only when its unwrapped pointer is one of them. The pointer is compared and never dereferenced before being accepted, so a foreign wrapped object is rejected rather than misread, and a reused address cannot alias because entries are removed in the destructor. It calls napi_unwrap directly rather than ObjectWrap::Unwrap, which throws for an object that was never wrapped -- that is what closes the Object.create case.

fill, stroke and addPath now throw TypeError for an argument that is not a Path2D, as browsers do, and addPath() reports a missing argument separately from a wrong-typed one. An unusable fillStyle/strokeStyle assignment leaves the previous value in place, as the spec requires.

The legal forms are unchanged and covered by a test: fill()/stroke() with no argument, an explicit undefined (which selects the no-argument overload rather than being a bad Path2D), a fill rule string, fill(path), fill(path, rule) and stroke(path).

new Path2D(x) does not throw. Per the (Path2D or DOMString) union a non-Path2D is converted to a string and parsed as path data, so new Path2D({ toString() { return "M0 0 L10 10"; } }) works and new Path2D({}) yields an empty path.

Validation

Unit tests: 21/21 suites, 49 JS assertions (was 43).
Visual sweep: ran=305 passed=305 failed=0; "Native Canvas" unchanged at 1.850%.
A/B on the original four holes: reverting only the C++ change fails exactly those tests and nothing else, without faulting -- unwrapping the wrong object reads plausible garbage rather than crashing, which is why it never showed up as a test failure.
A/B on the two prototype-spoof holes: both exit 0xC0000005 before the fix.

Throw assertions deliberately do not name the error type: a C++ Napi::TypeError surfaces as a JS TypeError on some engines and as an InternalError on the QuickJS Node-API port, so only the fact that it throws is portable. Every other throw test in this suite does the same.

Copilot

Pull request overview

This PR hardens the Canvas2D polyfill’s Path2D interop by preventing unsafe ObjectWrap::Unwrap calls on non-Path2D values, aligning fill, stroke, and addPath argument handling with browser behavior and adding regression coverage.

Changes:

Added NativeCanvasPath2D::IsInstance (mirroring CanvasGradient::IsInstance) and used it to gate all NativeCanvasPath2D::Unwrap call sites.
Updated Context2D.fill, Context2D.stroke, and Path2D.addPath to throw TypeError for non-Path2D arguments (while preserving the intended Path2D constructor behavior for non-Path2D inputs by stringifying them as path data).
Added unit tests covering the previously-unsafe argument forms and the still-valid overload forms.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
Polyfills/Canvas/Source/Path2D.h	Declares `NativeCanvasPath2D::IsInstance` for safe instance checking prior to `Unwrap`.
Polyfills/Canvas/Source/Path2D.cpp	Implements `IsInstance`, fixes `Path2D` constructor routing, and adds `addPath` argument validation before unwrapping.
Polyfills/Canvas/Source/Context.cpp	Adds `Path2D` instance checks (and `TypeError`s) to `fill`/`stroke` prior to unwrapping.
Apps/UnitTests/JavaScript/src/tests.javaScript.all.ts	Adds regression tests for invalid/valid `fill`/`stroke`/`addPath` argument forms and `Path2D` ctor behavior.
Apps/UnitTests/JavaScript/dist/tests.javaScript.all.js	Updates built test bundle corresponding to the new/updated TS tests.

💡 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 4 out of 5 changed files in this pull request and generated 1 comment.

bkaradzic-microsoft · 2026-08-20T16:20:12Z

+        // the global is writable, so script can replace it, and this has to answer whether the
+        // object is safe to Unwrap, not whether it matches whatever Path2D currently names.
+        const auto constructor = JsRuntime::NativeObject::GetFromJavaScript(env).Get(JS_PATH2D_CONSTRUCTOR_NAME);
+        return constructor.IsFunction() && value.As<Napi::Object>().InstanceOf(constructor.As<Napi::Function>());


You are right, and it is worse than a type-confusion risk -- both directions are a hard crash. Fixed in 4b37ddf.

I reproduced it before changing anything. Object.setPrototypeOf(gradient, Path2D.prototype) makes gradient instanceof Path2D true, and ctx.fill(gradient) then exits with 0xC0000005 on Win32 D3D11. Object.create(Path2D.prototype) passes the same check while having no native wrap behind it at all.

Checking the neighbouring type on your hint that a gradient was the vehicle: CanvasGradient::IsInstance had the identical gate, and it is reachable the other way round -- ctx.fillStyle = spoofedPath2D stores the impostor, and the next fill does CanvasGradient::Unwrap(...)->Paint(). Also 0xC0000005. Fixed both.

On the mechanism, I went through the options you implied:

napi_type_tag_object is the idiomatic answer, but only the V8 port implements it in this tree; the Chakra, JavaScriptCore and QuickJS ports do not, so it is not usable here.

A brand property is forgeable even under a symbol, since Object.getOwnPropertySymbols hands the symbol to script, which can then define it on any object.

So the authority has to live somewhere script cannot reach, which means C++. NativeInstanceRegistry<T> records the address of every live instance; a candidate is accepted only when its unwrapped pointer is one of them. The pointer is compared and never dereferenced before it is accepted, so a foreign wrapped object is rejected rather than misread, and a reused address cannot alias because entries are removed in the destructor. It also calls napi_unwrap directly instead of ObjectWrap::Unwrap, which throws for an object that was never wrapped -- that is what closes the Object.create case.

Both crashes now have regression tests, and they are the prototype-spoofed-native-object tests you asked for. Full run is 21/21 gtest suites and 49 JS assertions, up from 47. I also ran the 305-test visual sweep because the gradient draw path changed: 305/305, unchanged.

Follow-up: the first version of this fix reached the instance pointer through ObjectWrap::Unwrap, and that turned out not to be safe to call on an object that might never have been wrapped. Neither JsRuntimeHost Node-API port honours that part of the contract:

the V8 port dereferences internal field 0 unconditionally ([BABYLON-NATIVE-ADDITION] in js_native_api_v8.cc), so a plain object access-violates;

the QuickJS port falls back to walking the prototype chain, so it returns some other object's native pointer.

Object.create(Path2D.prototype) hit exactly this and crashed the V8 and QuickJS unit test runs.

So the check no longer calls Unwrap at all: each instance brands its own JS object with an External holding its address, and a candidate is accepted only if that address is still registered natively. Externals are opaque to script, and the address is compared, never dereferenced, before it is accepted.

An identity check against the instance's own object would also close brand-copying, but ObjectWrap::Value() throws on the QuickJS port, so it is not portable. It is not a memory-safety gap: copying a brand off a real instance yields that live instance, which the script already held, and a brand left over from a collected instance is rejected because the destructor unregisters the address.

Verified on Chakra, V8 and QuickJS: 21/21 gtest, 49 assertions each. Reverting only the C++ change reproduces the access violation. Visual sweep 305/305.

I'll file the napi_unwrap contract violations against JsRuntimeHost separately, since every ObjectWrap::Unwrap call site in BabylonNative has the same exposure.

Filed the promised follow-up: BabylonJS/JsRuntimeHost#226 covers the napi_unwrap contract violations (V8 port dereferences internal field 0 unchecked; QuickJS port falls back to walking the prototype chain).

Chasing the remaining CI failure on this PR turned up a second, separate port bug in the same area — BabylonJS/JsRuntimeHost#225, where the napi_throw family returns napi_pending_exception after a successful throw. That one makes every native throw on QuickJS escape WrapCallback and get rebuilt from e.what() after its handle scope has closed, which is the segfault in Ubuntu_Clang_QuickJS.

bkaradzic-microsoft · 2026-08-20T18:44:09Z

The remaining Ubuntu_Clang_QuickJS failure is not a Canvas bug — it is a Node-API port bug that this PR is the first thing to trip.

What the core dump says. The job uploaded a core this time. gdb puts the fault in the error reporting path, not in the type check:

#0  js_dup                       quickjs.c:1628          <-- SIGSEGV
#4  napi_get_value_string_utf8   js_native_api_quickjs.cc:696
#7  Napi::Error::Message         napi-inl.h:3087
#8  Napi::Error::what            napi-inl.h:3157
#9  ExternalCallback::Callback   js_native_api_quickjs.cc:164

The failing callback is InstanceWrap<NativeCanvasPath2D>::InstanceVoidMethodCallbackWrapper with argc=0, i.e. the path.addPath() assertion in the new rejects a non-Path2D argument to Path2D.addPath test. The JSValue being stringified has JS_TAG_STRING and an unaligned, freed pointer.

Root cause. The QuickJS port's napi_throw returns napi_pending_exception after a successful throw. node-addon-api reads that as "the throw failed" and re-throws Error::New(env), which consumes the pending exception, so the C++ exception escapes WrapCallback with no JS exception set. ExternalCallback::Callback then rebuilds the error from e.what() after the relevant handle scope has closed — a use-after-free.

This affects every native throw on QuickJS, not just Canvas. I instrumented that catch block locally: all ~50 native throws in the unit-test run escape WrapCallback. Linux faults; Windows happens to survive reading the freed string, which is why my local QuickJS build stayed green.

It also explains the InternalError: Uncaught C++ exception: ... messages I hit earlier in this PR — the real error is being replaced.

Fix: BabylonJS/JsRuntimeHost#225. Verified there with an A/B on Linux QuickJS: without the change expected 'InternalError' to equal 'Error' (1 failing), with it 213 passing.

So this PR is blocked on JsRuntimeHost#225 landing plus a pin bump, the same way #1835 waited on JsRuntimeHost#223. Everything else here is green (31/32), and the Canvas work itself is verified on Chakra, V8 and QuickJS locally (21/21 gtest, 49 assertions each) with a 305/305 visual sweep.

… them as Path2D/gradient # Conflicts: # Polyfills/Canvas/Source/Context.cpp

bkaradzic-microsoft · 2026-08-20T23:35:11Z

Confirming the loop is closed: BabylonJS/JsRuntimeHost#225 is merged, the pin here now points at 2390c63c34138a05c06c967d22687bb8e199a340, and CI is 32/32 green — including Ubuntu_Clang_QuickJS, which is the job that was segfaulting.

No change was needed to the Canvas code for that failure; it was the QuickJS Node-API port reporting failure from a successful napi_throw, so the new Path2D.addPath() arity check unwound into a use-after-free instead of surfacing a TypeError.

bghgary

[Reviewed by Copilot on behalf of @bghgary]

The type check belongs in JsRuntimeHost rather than here — comment inline. The call-site gating, the arity check and the tests all stand.

Not a complete review; holding the smaller points until the mechanism settles.

bghgary · 2026-08-21T20:39:14Z

+    // field 0 unconditionally, which access-violates, and the QuickJS port falls back to
+    // walking the prototype chain, which returns some other object's pointer.
+    //
+    // So each instance brands its own JS object with an External holding its address, and a


napi_type_tag_object is the Node-API answer to this, and it is unusable here only because three of the four ports do not implement it. V8 does (js_native_api_v8.cc:2556), storing the tag under a private key — invisible to script, absent from the prototype chain, not copyable onto another object. Implementing it in the QuickJS, Chakra and JavaScriptCore ports is the fix, and this file then deletes: Napi::Object::CheckTypeTag before Unwrap rejects both spoofs, with no brand property on the object and no process-wide set or mutex.

JsRuntimeHost#226 alone is not enough. It closes Object.create(Path2D.prototype), which was never wrapped, but a correct napi_unwrap still returns void* — so a CanvasGradient wearing Path2D.prototype is genuinely wrapped, unwraps successfully, and is used as a path. Only a tag distinguishes one wrapped type from another.

[Responded by Copilot on behalf of @bghgary]

We're picking up the JsRuntimeHost side — type tags in the QuickJS, Chakra and JavaScriptCore ports, plus the napi_unwrap guards from JsRuntimeHost#226. Flagging it so you don't start the same work; happy to hand it over if you'd rather take it, since you're already in that code.

This PR then waits on that landing and a pin bump.

Agreed — type tags are the right mechanism, and NativeInstanceRegistry.h deletes in favour of CheckTypeTag before Unwrap.

Your correction on #226 is right, and I'd overstated it: it only closes the never-wrapped Object.create case. A genuinely wrapped CanvasGradient wearing Path2D.prototype unwraps successfully no matter how correct napi_unwrap is. My registry separates the two types only because it is instantiated per T; the general form of that belongs in the port, not in Canvas.

One thing worth knowing before you start, because it makes this four ports rather than three: the V8 implementation is currently dead code.

js_native_api.h:4 carries a [BABYLON-NATIVE-ADDITION]:

#ifndef NAPI_VERSION #define NAPI_VERSION 5 #endif

That shadows upstream's default of 8, so the #if NAPI_VERSION >= 8 guard beginning at js_native_api_v8.cc:2555 never compiles. Confirmed against the build rather than by reading: in napi.lib (V8, RelWithDebInfo) napi_type_tag_object and napi_check_object_type_tag are both absent, while napi_unwrap and napi_create_external are present.

Raising NAPI_VERSION alone will not build it. NAPI_PRIVATE_KEY is commented out at js_native_api_v8_internals.h:79:

// [BABYLON-NATIVE-ADDITION]: Increase perf by using internal field instead of private property //#define NAPI_PRIVATE_KEY(context) \ // (v8::Private::New(context->GetIsolate()))

and no other definition exists in the tree, so the uses at 2565 and 2595 are unresolved. The internal-field route that comment points at needs a free slot and there isn't one: SetInternalFieldCount(1) at js_native_api_v8.cc:929, with field 0 already holding the Reference (363, 598). So it is restore the private key for tags, go to two internal fields, or carry the tag on the Reference.

Worth deciding deliberately either way: NAPI_VERSION 5 gates every other post-5 API as well, so bumping it is a wider change than type tags alone.

On the handoff — happy for you to take it, and I'll stay off it. If you'd rather split, I'll take the QuickJS port, since I was just in that file for #225.

One question on the interim. Both spoofs are a hard 0xC0000005 reachable from script on master today, and the tagging work is now larger than it looked. Would you like me to land the uncontroversial part of this PR first — the call-site gating, the addPath arity check and the tests — which closes the original four holes via InstanceOf, and leave the two prototype-spoof crashes to be closed properly by the tag? That keeps the spoof tests in the suite (failing-but-known, or skipped) rather than sitting on a branch. Or I'm equally happy to hold the whole PR until the tag lands, if you'd prefer one clean change.

[Responded by Copilot on behalf of @bghgary]

Hold the whole PR — one clean change once the tag lands. Nothing is blocked on it, and reaching either spoof takes script that deliberately re-prototypes a canvas object; nothing in Babylon.js does that.

We'll take all four ports.

Understood — holding it. Agreed on the risk call: both spoofs need script that deliberately re-prototypes a canvas object, so there's nothing to race here.

I'll leave the branch rebased and green, and when the tags land I'll swap NativeInstanceRegistry.h for CheckTypeTag, bump the pin, and re-run. The two spoof tests stay in the suite as the regression cover for the port work.

Marking this a draft in the meantime so it doesn't sit in your review queue. Ping me if you want the QuickJS port after all.

bkaradzic-microsoft · 2026-08-21T22:41:16Z

Rebased onto master (85355d87), now 5 commits with no merge. Force-pushed as a1aab5e1.

The one conflict was against #1843: BindFillStyle/BindStrokeStyle moved their style members into m_state, and this PR changes the same two lines from Unwrap to the checked TryUnwrap. Resolved by keeping the check and taking the m_state members.

Re-verified after the rebase rather than assuming: 21/21 gtest suites, all the new spoof/gradient tests passing, and the visual sweep still ran=305 passed=305 failed=0 with "Native Canvas" unchanged at 1.850%.

Still blocked on the type-tag work as discussed above — the rebase is just to keep it mergeable.

ObjectWrap::Unwrap does no type checking, so handing it an object that is not a NativeCanvasPath2D reinterprets unrelated memory as one. Four call sites reached it without establishing that: ctx.stroke(x) no check at all -- ctx.stroke("x") cast a string ctx.fill(x) gated on IsObject(), so ctx.fill({}) still got through new Path2D(x) gated on IsObject(), same hole path.addPath(x) no type check and no arity check, so addPath() also unwrapped a missing argument Add NativeCanvasPath2D::IsInstance, mirroring CanvasGradient::IsInstance, and check it before every Unwrap. It tests against the constructor kept on the native object rather than the global one, because the global is writable and the question being asked is whether the object is safe to unwrap, not whether it matches whatever Path2D currently names. fill/stroke/addPath now throw TypeError for an argument that is not a Path2D, as browsers do. The legal forms are unchanged: fill() and stroke() with no argument, an explicit undefined (which selects the no-argument overload), a fill rule string, and a Path2D. Per the (Path2D or DOMString) union, new Path2D(x) converts a non-Path2D to a string and parses it as path data rather than throwing.

A C++ Napi::TypeError surfaces as a JS TypeError on Chakra and V8 but as "InternalError: Uncaught C++ exception" on the QuickJS Node-API port, so asserting the constructor fails the Ubuntu_Clang_QuickJS job. Assert only that the call throws, which is what every other throw test in this suite already does. Also split addPath's arity check from its type check so a missing argument no longer reports that the first argument has the wrong type.

The IsInstance gates added earlier tested `instanceof` against the stored constructor. That only walks the prototype chain, and a prototype is assignable from script, so the check they were meant to make was still bypassable: Object.setPrototypeOf(gradient, Path2D.prototype); ctx.fill(gradient); // unwraps a CanvasGradient as a NativeCanvasPath2D Both directions crash with an access violation, confirmed on Win32 D3D11: the Path2D case through fill/stroke/addPath, and the gradient case through `ctx.fillStyle = spoofedObject` followed by any fill. Object.create with the right prototype gets through the same way while having no native wrap behind it at all. napi_type_tag_object would be the idiomatic fix, but only the V8 port implements it -- Chakra, JavaScriptCore and QuickJS do not -- and a brand property is reachable through Object.getOwnPropertySymbols and copyable onto any object. So the authority moves into C++, where script cannot reach it: NativeInstanceRegistry records the address of every live instance, and a candidate is accepted only when its unwrapped pointer is one of them. The pointer is compared, never dereferenced, before being accepted, so a foreign wrapped object is rejected instead of misread. napi_unwrap is called directly rather than through ObjectWrap::Unwrap, which throws for an object that was never wrapped.

The registry added in the previous commit still reached the instance pointer through ObjectWrap::Unwrap, which is not safe to call on an object that may never have been wrapped. Neither JsRuntimeHost port honours that contract: the V8 port dereferences internal field 0 unconditionally and access-violates, and the QuickJS port falls back to walking the prototype chain and returns some other object's pointer. Object.create(Path2D.prototype) crashed the V8 and QuickJS unit test runs for exactly this reason. Each instance now brands its own JS object with an External holding its address, and a candidate is accepted only if that address is still registered. Externals are opaque to script and the address is compared, never dereferenced, before it is accepted. Verified on Chakra, V8 and QuickJS: 21/21 gtest, 49 assertions. Reverting only the C++ change reproduces the access violation. Visual sweep 305/305. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09

Copilot AI lite review requested due to automatic review settings August 20, 2026 00:41

Copilot started reviewing on behalf of bkaradzic-microsoft August 20, 2026 00:47 View session

Copilot AI reviewed Aug 20, 2026

View reviewed changes

Comment thread Polyfills/Canvas/Source/Path2D.cpp Outdated

bkaradzic-microsoft mentioned this pull request Aug 20, 2026

Canvas: clip() does not clip to the path (needs real stencil-based path clipping) #1845

Open

bkaradzic-microsoft requested review from bghgary and a balanced review from Copilot August 20, 2026 13:56

Copilot started reviewing on behalf of bkaradzic-microsoft August 20, 2026 13:57 View session

Copilot AI reviewed Aug 20, 2026

View reviewed changes

bkaradzic-microsoft changed the title ~~Canvas: reject non-Path2D arguments instead of unwrapping them~~ Canvas: reject foreign objects instead of unwrapping them as a Path2D or gradient Aug 20, 2026

bkaradzic-microsoft mentioned this pull request Aug 20, 2026

napi_unwrap does not reject objects that were never wrapped (V8 port faults, QuickJS port confuses types) BabylonJS/JsRuntimeHost#226

Open

bkaradzic-microsoft pushed a commit to bkaradzic-microsoft/BabylonNative that referenced this pull request Aug 20, 2026

Merge PR BabylonJS#1844: reject foreign objects instead of unwrapping…

968a1d6

… them as Path2D/gradient # Conflicts: # Polyfills/Canvas/Source/Context.cpp

bkaradzic-microsoft force-pushed the canvas-path2d-isinstance branch from bac7ca0 to 68300c1 Compare August 20, 2026 22:44

bghgary requested changes Aug 21, 2026

View reviewed changes

bkaradzic-microsoft requested a review from bghgary August 21, 2026 22:31

bkaradzic-microsoft force-pushed the canvas-path2d-isinstance branch from 68300c1 to a1aab5e Compare August 21, 2026 22:35

bkaradzic-microsoft marked this pull request as draft August 22, 2026 00:23

bkaradzic-microsoft force-pushed the canvas-path2d-isinstance branch from a1aab5e to 7e0caab Compare August 25, 2026 21:01

bkaradzic and others added 4 commits August 26, 2026 18:05

bkaradzic-microsoft force-pushed the canvas-path2d-isinstance branch from 7e0caab to 6e1444c Compare August 27, 2026 01:07

Uh oh!

Conversation

bkaradzic-microsoft commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change

Validation

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bkaradzic-microsoft commented Aug 20, 2026

Uh oh!

bkaradzic-microsoft commented Aug 20, 2026

Uh oh!

bghgary left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bkaradzic-microsoft commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

bkaradzic-microsoft commented Aug 20, 2026 •

edited

Loading