RichEditBox Pastes Twice With DisabledFormattingAccelerators="All"

RichEditBox is pasting text twice with DisabledFormattingAccelerators="All" in xaml. The clipboard contents are correct when copying from the app and pasting into another app. With a custom paste handler using Paste="MyPasteHandler", the handler is called twice. It only seems to happen when the text is highlighted with the mouse and the copy command is issued with the keyboard, but once the bug happens, all further copies and pastes are affected until the app is restarted.

Steps to reproduce the bug Steps to reproduce the behavior:

1. Create a new project using the Blank UWP C# template
2. Add a RichEditBox to the xaml as <RichEditBox DisabledFormattingAccelerators="All"></RichEditBox>
3. Launch the app
4. Select some text using the mouse
5. Copy the text
6. Paste using ctrl+v
7. Sometimes you have to repeat (4), (5), and (6) one more time before the bug occurs

Expected behavior Expected behavior: the copied text is pasted once Actual behavior: the copied text is pasted twice

Screenshots https://user-images.githubusercontent.com/6198756/105638586-5e206a80-5e41-11eb-8ad3-526003795a15.mp4

Version Info

NuGet package version: [Microsoft.UI.Xaml.Markup 10.0.0.0] (not sure what other package versions are relevant)

Windows app type:

UWP	Win32
Yes

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2020 Update (19041)	Yes
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

Additional context

[queequac]

I have the same issue when the content got selected before pasting. From then on it does not need any selection anymore, the past-event gets simply fired twice on every Ctrl-V. 😕

Also no DisabledFormattingAccelerators required… I am not using WinUI but “original” UWP XAML targeting 19041.

Interesting point: RichEditBox’s Paste event is fired twice then. But while the CoreWindows’s first KeyDown event for Ctrl+V is usually “eaten” by the system on the regular paste, it gets at least fired from then on once in above strange situation. Looks like some issue backed into the system.

[Parth]

We’re using WinUI2