`WinUI.TableView` crashes on Ctrl+C inside editable cell due to unhandled clipboard exception

[mavaddat]

Summary

Pressing Ctrl+C inside an editable TableViewTemplateColumn cell causes a WinRT clipboard exception to escape the control and crash the application. The exception is thrown from Clipboard.SetContent inside TableView.CopyToClipboardInternal, and it is not caught by the control.

This issue occurs only inside WinUI.TableView.
Copying from TextBox, RichEditBox, or any other WinUI 3 control does not reproduce the crash.

The exception does not reach Application.UnhandledException, because it is intercepted by the auto‑generated XAML handler in App.g.i.cs, causing the debugger to break immediately.

This makes the crash unavoidable unless the app manually intercepts Ctrl+C inside the cell editor.

---

Affected Version

WinUI.TableView 1.3.4
Windows App SDK 1.6.250108002
.NET 8.0
Windows 10.0.19041

---

Reproduction Steps

1. Create a WinUI 3 app.
2. Add a TableView with a TableViewTemplateColumn containing a TextBox (editable cell).
3. Run the app.
4. Click inside the editable cell to focus the TextBox.
5. Press Ctrl+C.

---

Actual Behavior

The application crashes with an unhandled WinRT clipboard exception:

HResult: -2147221040 (0x800401D0)
CLIPBRD_E_CANT_OPEN

Stack trace:

WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|38_0(Int32 hr)
ABI.Windows.ApplicationModel.DataTransfer.IClipboardStaticsMethods.SetContent(...)
Windows.ApplicationModel.DataTransfer.Clipboard.SetContent(DataPackage content)
WinUI.TableView.TableView.CopyToClipboardInternal(Boolean includeHeaders)
WinUI.TableView.TableView.HandleShortKeys(Boolean shiftKey, Boolean ctrlKey, VirtualKey key)
WinUI.TableView.TableView.OnKeyDown(KeyRoutedEventArgs e)
ABI.Microsoft.UI.Xaml.Controls.IControlOverrides.Do_Abi_OnKeyDown_18(...)

The exception is not handled by the control and does not reach Application.UnhandledException.

---

Expected Behavior

• Pressing Ctrl+C inside an editable cell should either:
  • Copy the selected text normally (preferred), or
  • Do nothing, or
  • Fail silently

It should not crash the application.

Clipboard access is known to fail intermittently on Windows (e.g., when another process temporarily locks the clipboard). Controls that call Clipboard.SetContent should wrap it in a try/catch.

---

Minimal Reproducible Example

MainWindow.xaml

<Window
    x:Class="TableViewCrashTest.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:tv="using:WinUI.TableView">

    <Grid>
        <tv:TableView x:Name="MyTable"
                      AutoGenerateColumns="False">
            <tv:TableView.Columns>

                <tv:TableViewTemplateColumn Header="Editable">
                    <tv:TableViewTemplateColumn.CellTemplate>
                        <DataTemplate>
                            <TextBox Text="{Binding Value, Mode=TwoWay}"
                                     BorderThickness="0"
                                     Padding="4" />
                        </DataTemplate>
                    </tv:TableViewTemplateColumn.CellTemplate>
                </tv:TableViewTemplateColumn>

            </tv:TableView.Columns>
        </tv:TableView>
    </Grid>
</Window>

MainWindow.xaml.cs

public sealed partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();

        MyTable.ItemsSource = new[]
        {
            new TestRow { Value = "Try Ctrl+C here" }
        };
    }
}

public class TestRow
{
    public string Value { get; set; }
}

Repro Instructions

1. Run the app.
2. Click inside the TextBox cell.
3. Press Ctrl+C.
4. Application crashes with CLIPBRD_E_CANT_OPEN.

---

Additional Notes

• The issue only occurs inside WinUI.TableView.
• Copying from:
  • TextBox
  • RichEditBox
  • Any other WinUI 3 control
    does not reproduce the crash.
• The exception originates inside TableView.CopyToClipboardInternal.
• The control does not wrap clipboard access in a try/catch.
• Because the exception is thrown inside WinRT interop, it bypasses Application.UnhandledException and triggers the auto‑generated XAML break handler.

---

Workaround

Intercept Ctrl+C inside the cell editor:

private void CellEditor_KeyDown(object sender, KeyRoutedEventArgs e)
{
    var ctrl = InputKeyboardSource.GetKeyStateForCurrentThread(VirtualKey.Control)
                 .HasFlag(CoreVirtualKeyStates.Down);

    if (ctrl && e.Key == VirtualKey.C)
        e.Handled = true;
}

This prevents the crash but potentially disables copy functionality inside the TableView (it seems that copy still works even with this intercept).

---

Request

Please update TableView.CopyToClipboardInternal to:

• Wrap Clipboard.SetContent in a try/catch
• Avoid propagating WinRT clipboard exceptions
• Optionally check clipboard availability before calling SetContent

This will prevent application crashes and align the control with expected WinUI behavior.

[mavaddat]

🎯 The exact source of the issue

The problem is this line:

Clipboard.SetContent(package);

…and the fact that it is executed without any exception handling.

That’s the entire bug.

---

🧨 Why this line crashes the app

Clipboard.SetContent is a WinRT/COM API.
It is not reliable. It can fail at any time with:

0x800401D0  (CLIPBRD_E_CANT_OPEN)

This happens when:

• Another process has the clipboard open
• The clipboard is temporarily locked
• The OS denies access for any reason
• The app is in a state where clipboard access is not allowed

These failures are normal and expected on Windows.

But because CopyToClipboardInternal does not wrap the call in a try/catch, the exception:

• Escapes the method
• Escapes the control
• Escapes WinUI
• Escapes the dispatcher
• Hits the auto‑generated XAML unhandled exception hook
• Breaks the debugger in App.g.i.cs
• Crashes the app in release builds

This is exactly the behavior observed in this bug.

---

🧩 Why TextBox copy still works

Because:

• The TextBox handles Ctrl+C internally
• It copies text using its own clipboard logic
• Your interceptor marks the event handled
• So TableView.HandleShortKeys never runs
• Therefore CopyToClipboardInternal never runs
• Therefore the crash never happens

This confirms the bug is 100% inside TableView, not WinUI 3.

---

🛠 What the control should do

At minimum:

try
{
    Clipboard.SetContent(package);
}
catch (Exception ex)
{
    // swallow or log — clipboard failures must NEVER crash the app
}

Better:

• Skip TableView-level copy when a cell editor already handled Ctrl+C
• Provide a CopyCommand override point
• Allow disabling built‑in copy behavior

---

📌 Summary

The source of the issue is:

❌ Clipboard.SetContent(package) is called without exception handling

❌ TableView handles Ctrl+C even when a cell editor already handled it

❌ WinRT clipboard exceptions propagate as fatal XAML exceptions

Your workaround (intercepting Ctrl+C inside the cell editor) works because it prevents TableView from reaching this buggy code path.

If you want, I can help you write a PR patch for the library that:

• Adds proper exception handling
• Avoids duplicate copy handling
• Makes the control robust and safe for production apps

[mavaddat]

Any update on this @w-ahmad?