API Review: Custom context menu Spellcheck by anuragkumar878 · Pull Request #5553 · MicrosoftEdge/WebView2Feedback

anuragkumar878 · 2026-03-31T05:27:13Z

Spellcheck Suggestions for Custom Context Menus

Enables host apps rendering custom context menus to discover, retrieve, and apply spellcheck suggestions for misspelled words in editable fields. Introduces a
deferred capability discovery pattern on EventArgs2 that is extensible to future async capabilities without additional EventArgs versions.

New Interfaces:

ICoreWebView2ContextMenuRequestedEventArgs2 extends ICoreWebView2ContextMenuRequestedEventArgs

get_DeferredCapabilities(flags*) — Returns a bitmask indicating which async capabilities are available for this context menu invocation (e.g., SPELL_CHECK).
GetDeferredCapability(REFIID, void**) — IID-based accessor to acquire a capability interface. Returns E_NOINTERFACE if the capability is not applicable.

ICoreWebView2ContextMenuSpellCheck (acquired via GetDeferredCapability)

get_MisspelledWord(LPWSTR*) — Returns the misspelled word under the cursor.
GetSpellCheckSuggestionsAsync(handler) — Registers a one-shot completion handler that fires exactly once (always asynchronously) with spellcheck suggestions.
Fires immediately (via PostTask) if suggestions are already resolved, or deferred until ready.

ICoreWebView2GetSpellCheckSuggestionsCompletedHandler

Invoke(errorCode, suggestions) — Callback delivering an HRESULT and an ICoreWebView2ContextMenuItemCollection. Each item is a standard
ICoreWebView2ContextMenuItem with Label (suggestion text) and CommandId (opaque identifier).

Usage flow:

Host receives ContextMenuRequested, QIs for EventArgs2
Checks DeferredCapabilities for SPELL_CHECK flag
Calls GetDeferredCapability(IID_SpellCheck) to acquire spellcheck interface
Sets Handled = TRUE, takes deferral
Reads MisspelledWord, calls GetSpellCheckSuggestionsAsync with handler
Handler fires with ICoreWebView2ContextMenuItemCollection → host builds menu
User selects → host sets args->put_SelectedCommandId(item->CommandId)
Completes deferral — runtime applies the correction via unified commanding

Key design decisions:

Suggestions returned as ICoreWebView2ContextMenuItem objects (not strings) — consistent with existing menu item types
Unified commanding via SelectedCommandId — same path as Cut, Copy, Paste; no separate ApplySpellCheckSuggestion method
Suggestion item Name set to "spellCheckSuggestion" for machine-readable identification
E_ILLEGAL_METHOD_CALL on double handler registration (no silent replacement)
Direct QI for SpellCheck from EventArgs returns E_NOINTERFACE — forces EventArgs2 discovery path to distinguish "old runtime" from "not applicable"

anuragkumar878 · 2026-03-31T06:43:37Z

@microsoft-github-policy-service agree company="Microsoft"

Copilot

Pull request overview

This PR introduces a new API review spec to extend the existing WebView2 ContextMenuRequested customization flow with spellcheck support, enabling hosts that render custom context menus to surface and apply spellcheck suggestions.

Changes:

Adds a new spec describing custom-context-menu spellcheck scenarios and motivation.
Provides Win32 C++ and C# example flows for querying suggestions, handling async readiness, and applying a suggestion.
Proposes new Win32 COM interfaces (ICoreWebView2ContextMenuTarget2, ICoreWebView2ContextMenuRequestedEventArgs2) plus corresponding .NET/WinRT projections.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

specs/CustomContextMenuSpellcheck.md

Copilot

Pull request overview

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

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

specs/CustomContextMenuSpellcheck.md

shrinaths

Review Summary

The architecture and design are sound — DeferredCapabilityDiscovery, ContextMenuItemCollection return type, unified SelectedCommandId commanding, and always-async callback are all well done. The comments below focus on bringing the spec up to the polish expected for Windows API review board submission:

Must fix:

Placeholder UUIDs (lines 260, 298, 320) — generate real values
.NET projection should use [interface_name] pattern, not EventArgs2 class (line 363)
Verify MIDL3 format requirement with SDK team (line 233)

Should fix:

Rename title to "Spellcheck Support for Custom Context Menus"
Complete the samples (both C++ and C# have undefined helpers / placeholder comments)
Add CHECK_FAILURE() consistently in C++ sample
Fix SelectedCommandId default value in error table (it's -1, not 0)

Nit:

Consistent casing of "spellcheck" in prose
Avoid contractions per Microsoft style guide
Use /// doc comments in .NET projection
Clean up casual language ("for example -")

specs/CustomContextMenuSpellcheck.md

david-risney · 2026-04-09T19:32:09Z

specs/CustomContextMenuSpellcheck.md

+                [this, args, spellCheck, items, deferral,
+                 word = std::wstring(misspelledWord.get())]()
+                {
+                    spellCheck->GetSpellCheckSuggestionsAsync(


The implication of this sample code is that GetSpellCheckSuggestionsAsync is fast enough that you can delay showing the entire context menu until it async completes. Is this always true? I thought at some point the browser would show an initial context menu and then update it async later when the spell check suggestions become available. This should be documented.

Correct, it's not always instant. The platform spellchecker runs asynchronously in the browser process. When ContextMenuRequested fires, suggestions may already be resolved (kReady) or still in flight (kNotReady). GetSpellCheckSuggestions abstracts this, the handler fires on the next message loop iteration if ready, or when the IPC response arrives if not.

The sample uses the simpler "wait-then-show" pattern. In practice the delay is typically imperceptible (suggestions often resolve before or within milliseconds of the event), but it's not guaranteed.

I've added an "Async Timing" section to the spec documenting both host patterns:

Pattern 1 (wait-then-show) — simpler, used in the sample, delays menu if suggestions aren't ready

Pattern 2 (show-then-update) — shows menu immediately with placeholder, updates when handler fires (mirrors browser built-in behavior)

@anuragkumar878 Lets explain this subtelty in the doc for completeness.

david-risney · 2026-04-09T19:33:50Z

specs/CustomContextMenuSpellcheck.md

+                                    cur->get_Name(&name);
+                                    // Skip built-in spellcheck items already
+                                    // handled above.
+                                    if (wcsstr(name.get(), L"spellCheck"))


Why is this built-in spellcheck item here and what is the relationship between it and this new spellcheck work? Should we be placing the new spell check menu items in place of this menu item rather than at the top? We should document this.

GetSpellCheckSuggestions returns separate objects (Name = "spellCheckSuggestion", different CommandId values) representing the same underlying suggestions, delivered through the new async API. Both exist because the built-in items maintain backward compatibility for hosts that don't use the new API.

On placement: The sample puts new suggestions at the top and filters out the built-in duplicates. Hosts that want to preserve the original position can scan MenuItems for the first "spellcheck" entry's index and insert there instead.

Details added in the spec.

david-risney · 2026-04-09T19:37:25Z

specs/CustomContextMenuSpellcheck.md

+
+**Async contract:** The handler fires exactly once, always asynchronously (posted to the caller's
+message loop, never invoked inline). Only one handler may be registered; a second call returns
+`E_ILLEGAL_METHOD_CALL`.


Does this mean you can't call GetSpellCheckSuggestionsAsync twice? We should be able to call GetSpellCheckSuggestionsAsync more than once. Or what exactly does it mean by 'Only one handler may be registered'? If this trying to describe standard async method behavior then you can just say that instead.

Updated the spec to allow calling GetSpellCheckSuggestions multiple times supported.

david-risney · 2026-04-09T19:39:15Z

specs/CustomContextMenuSpellcheck.md

+            /// Retrieves the capability-specific interface for a deferred
+            /// capability. Returns null if the capability is not applicable.
+            /// </summary>
+            T GetDeferredCapability<T>();


The deferred capability APIs seem unnecessarily complex. Instead lets put CoreWebView2ContextMenuSpellCheck directly as a SpellCheck property on ICoreWebView2ContextMenuRequestedEventArgs2. We already have to handle cases where its an old runtime and the newer interface isn't supported and have the end dev have a way to detect and handle this case. For additional cases where its a newer runtime but spell check is not available we can have a null SpellCheck property.

Making EventArgs2 spellcheck specific was our first instinct. But we have since reconsidered.

Consider future extensions - supporting emoji's. In that case EventArgs2 would have to be extended to EventArgs3 and embellished with emoji specific properties. Since there is no "is-a" relationship between Spellcheck and Emoji functionality ... an extension like this would make little sense.

Therefore we have created EventArgs2 with a way enumerate which capability is it that this Event refers to and then query the respective interface to access further event specific details which are otherwise unrelated to each other. The "is-a" relationship is with EventArgs but not amongst each other.

Hope that explains.

specs/CustomContextMenuSpellcheck.md

david-risney · 2026-04-09T19:43:37Z

specs/CustomContextMenuSpellcheck.md

+  /// the correction.
+  ///
+  /// Only one handler may be registered per event invocation. A second call
+  /// returns `E_ILLEGAL_METHOD_CALL`.


Same question about calling the method multiple times I had at the top. We shouldn't throw if you call the method more than once.

Removed the E_ILLEGAL_METHOD_CALL guard and now support multiple calls. Each call registers its own handler; all fire with the same results when suggestions resolve

initial api design

417e474

Anurag Kumar added 2 commits March 31, 2026 12:18

usage refactoring

aab5c7a

rename md file

db3dacb

anuragkumar878 requested a review from Copilot March 31, 2026 13:54

Copilot started reviewing on behalf of anuragkumar878 March 31, 2026 13:56 View session

Copilot AI reviewed Mar 31, 2026

View reviewed changes

remove misspelled word, split propget on context menu info

c7d73db

MicrosoftEdge deleted a comment from Copilot AI Apr 1, 2026

Anurag Kumar added 2 commits April 1, 2026 12:00

use a one shot callback handler instead of event registration

d2397e0

keep only async approach

4615e97

anuragkumar878 added the API Proposal Review WebView2 API Proposal for review. label Apr 1, 2026

anuragkumar878 marked this pull request as ready for review April 1, 2026 10:33

anuragkumar878 requested a review from Copilot April 2, 2026 04:53

Copilot started reviewing on behalf of anuragkumar878 April 2, 2026 04:54 View session

Copilot AI reviewed Apr 2, 2026

View reviewed changes

specs/CustomContextMenuSpellcheck.md Outdated Show resolved Hide resolved

specs/CustomContextMenuSpellcheck.md Outdated Show resolved Hide resolved

specs/CustomContextMenuSpellcheck.md Outdated Show resolved Hide resolved

specs/CustomContextMenuSpellcheck.md Outdated Show resolved Hide resolved

Anurag Kumar added 3 commits April 5, 2026 22:12

api changed to be a seperate interface

a170b51

update api spec as per feedback

e4be188

minor name refactoring

cc97cc8

shrinaths reviewed Apr 7, 2026

View reviewed changes

Anurag Kumar added 2 commits April 8, 2026 13:58

review commits addressed

74ae966

review comment addressed

77ae92e

shrinaths reviewed Apr 8, 2026

View reviewed changes

specs/CustomContextMenuSpellcheck.md Show resolved Hide resolved

specs/CustomContextMenuSpellcheck.md Outdated Show resolved Hide resolved

minor refactoring of spec

bdea768

david-risney requested changes Apr 9, 2026

View reviewed changes

review comments addressed

e29d67c

Conversation

anuragkumar878 commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anuragkumar878 commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

shrinaths left a comment

Choose a reason for hiding this comment

Review Summary

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

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!

shrinaths Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

anuragkumar878 commented Mar 31, 2026 •

edited

Loading

anuragkumar878 commented Mar 31, 2026 •

edited

Loading

shrinaths Apr 10, 2026 •

edited

Loading