MicrosoftEdge / MicrosoftEdge/WebView2Feedback

[Bug] Copied content from WebView2 doesn't appear in Windows Clipboard History (Win+V)

Open
#5,650 1 comment 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PowerShell
Stars
526
Forks
67
PR merge metrics
No merged PRs in 30d

Description

@@ -0,0 +1,280 @@

WebView2 Feedback: Clipboard Content Not Appearing in Windows Clipboard History

Summary

Issue: Content copied with Ctrl+C in WebView2 works with Ctrl+V paste, but does NOT appear in Windows Clipboard History (Win+V).

Impact: Breaks expected Windows clipboard behavior, affects user workflow and productivity.

Affected Versions: WebView2 Runtime (all tested versions including latest stable)

Operating System: Windows 10 version 1809+, Windows 11

Description

When users press Ctrl+C to copy content within a WebView2 control, the clipboard operation appears to work correctly - Ctrl+V paste functions as expected. However, the copied content does not appear in the Windows Clipboard History feature (accessed via Win+V), which is a core Windows 10/11 feature.

Expected Behavior
  1. User selects text in WebView2 control
  2. User presses Ctrl+C to copy
  3. Content is copied to clipboard (Ctrl+V works) ✓
  4. Content appears in Windows Clipboard History (Win+V) ✗ FAILS
Actual Behavior
  • Ctrl+V paste: Works correctly
  • Win+V clipboard history: Content does NOT appear
  • Other Windows applications: Clipboard history works normally

Root Cause Analysis

After extensive investigation, we identified the issue:

WebView2/Chromium uses an internal window handle as the clipboard owner that is not recognized by Windows Clipboard History service.

Technical Details
  1. When WebView2 handles Ctrl+C, it uses Chromium's internal clipboard mechanism
  2. The clipboard owner window handle is set to an internal Chromium window
  3. Windows Clipboard History service does not recognize this window handle
  4. Result: Clipboard data is valid, but history service ignores the clipboard change
Evidence
  • Using Spy++ to inspect clipboard operations shows:

    • Clipboard owner: Internal WebView2/Chromium window
    • Clipboard formats: Correctly set (CF_UNICODETEXT, CF_HTML, etc.)
    • Windows Clipboard History: Not triggered
  • Using Clipboard API monitoring tools confirms:

    • OpenClipboard() is called with non-standard window handle
    • SetClipboardData() succeeds
    • GetClipboardSequenceNumber() increments correctly
    • But Windows Clipboard History does not capture the event

Our Workaround Solution

We implemented a workaround in our application by:

  1. Intercepting Ctrl+C key events in AcceleratorKeyPressed handler
  2. Allowing WebView2 to perform the copy operation first (preserves rich content)
  3. After 100ms delay, re-taking clipboard ownership:
    • Opening clipboard with our application's window handle
    • Enumerating all existing clipboard formats
    • Copying the data
    • Emptying clipboard and re-setting all formats with our window as owner
  4. This makes Windows Clipboard History recognize the clipboard change

Result: This workaround successfully makes clipboard history work, but adds complexity and ~100ms latency.

Reproduction Steps

Minimal Reproduction
  1. Create a simple WebView2 application (WPF/WinForms/Win32)
  2. Load any webpage with copyable text
  3. Ensure Windows Clipboard History is enabled (Settings → System → Clipboard)
  4. Select text in the WebView2 control
  5. Press Ctrl+C to copy
  6. Press Win+V to open Clipboard History
  7. Observe: Copied text does NOT appear in history
Sample Code
// WPF example
<Window>
    <wv2:WebView2 x:Name="webView" Source="https://example.com"/>
</Window>

// Steps:
// 1. Run application
// 2. Wait for page to load
// 3. Select text
// 4. Press Ctrl+C
// 5. Press Win+V → Text not in history

Requested Solution

We request one of the following solutions from the WebView2 team:

Option 1: Use Host Window Handle (Preferred)

Modify WebView2 to use the host application's window handle as the clipboard owner instead of an internal Chromium window.

Benefits:

  • Simple fix
  • No API changes required
  • Clipboard history works automatically
  • Maintains all existing functionality

Implementation:

  • When opening clipboard, use the CoreWebView2Controller's parent window handle
  • This window is already known to Windows and properly registered
Option 2: Add Clipboard API

Provide a clipboard API that allows host applications to control clipboard operations:

// Proposed API
webView.Settings.UseHostClipboard = true; // Use host's clipboard mechanism
// OR
webView.CoreWebView2.ClipboardManager.SetOwnerWindow(hostWindowHandle);

Benefits:

  • Gives applications control
  • Opt-in for backward compatibility
  • Flexible for different scenarios
Option 3: Trigger Clipboard History Properly

Ensure WebView2's internal clipboard operations properly trigger Windows Clipboard History, even with internal window handles.

Implementation:

  • Call appropriate Windows APIs to notify clipboard history
  • Or flush delayed clipboard rendering to ensure history captures it

Impact Assessment

User Impact
  • High: Users expect clipboard history to work consistently across all applications
  • Frequency: Every copy operation in WebView2 is affected
  • Workaround: Requires application developers to implement complex workarounds
  • Discoverability: Users may not realize the issue until they try Win+V
Developer Impact
  • Workaround complexity: Requires ~100-200 lines of code
  • Maintenance burden: Must handle all clipboard formats (text, HTML, RTF, images)
  • Performance overhead: Additional 100ms delay and memory copies
  • Compatibility risk: Workaround may break with WebView2 updates

Environment Details

  • WebView2 Runtime Version: 131.0.2903.86 (and earlier versions)
  • WebView2 SDK Version: 1.0.2792.45
  • Operating System: Windows 10 21H2, Windows 11 23H2
  • Application Type: Win32 C++ (WPF/WinForms also affected)
  • Host Application: Zoom Desktop Client (Windows)

Additional Context

Related Windows Features Affected
  • Windows Clipboard History (Win+V)
  • Cloud Clipboard sync (if enabled)
  • Third-party clipboard managers (some work, some don't)
Similar Issues in Other Frameworks
  • Electron: Similar issue reported, fixed in v12.0.0 by using native clipboard APIs
  • CEF (Chromium Embedded Framework): Provides clipboard delegation to host
User Reports

We have received user feedback reporting this issue:

  • "Clipboard history doesn't work in Zoom web content"
  • "Can't access copy history from Help center"
  • "Win+V is empty after copying from app"

Testing Recommendations

Test Cases for Verification
  1. Basic text copy: Copy plain text, verify appears in Win+V
  2. Rich text copy: Copy formatted text, verify formatting preserved and appears in Win+V
  3. Image copy: Copy image, verify appears in Win+V (if supported)
  4. Multiple copies: Copy multiple items, verify all appear in history
  5. Cross-application paste: Copy from WebView2, paste in other apps via Win+V
Verification Criteria
  • ✓ Content appears in Windows Clipboard History within 200ms
  • ✓ All clipboard formats are preserved (text, HTML, RTF, images)
  • ✓ Clipboard history shows correct preview
  • ✓ Selecting from history pastes correctly
  • ✓ No performance regression
  • ✓ Backward compatible with existing applications

References

Documentation
Related Issues

Contact Information

  • Reporter: Zoom Video Communications, Inc.
  • Component: Desktop Client - Windows
  • Email: yingxing.xie@zoom.us
  • Willing to test fixes: Yes
  • Can provide more info: Yes

Priority Justification

Severity: Medium to High

Justification:

  • Affects all WebView2 applications on Windows 10/11
  • Breaks expected Windows platform behavior
  • Requires complex workarounds
  • User-visible functionality gap
  • Impacts productivity workflows

Requested Timeline: Include in next major release

Proposed Documentation Update

If immediate fix is not possible, please document this limitation:

Known Issue: Content copied from WebView2 may not appear in Windows Clipboard History (Win+V). This is due to Chromium's internal clipboard handling. Workaround: Applications can intercept clipboard operations and re-set clipboard data with the host window handle as owner.


Thank you for considering this feedback. We believe fixing this issue will significantly improve the WebView2 experience for all Windows users.

Feedback Date: 2025-01-21
WebView2 Version Tested: 131.0.2903.86
Feedback ID: CLIPBOARD-HISTORY-001

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the WebView2 reproduction steps and the AcceleratorKeyPressed handler described in the issue, then review CoreWebView2Controller's parent-window handling. Test plain text, rich text, images, and repeated copies with Win+V on Windows 10 or 11. Done means copied content appears in Clipboard History while preserving formats and paste behavior without the application workaround.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, csharp
Domain
desktop, operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.