[Backport to release/10.0]: Clipboard.GetText(TextDataFormat.Rtf) does not retrieve RTF that lacks a null terminating character#14527
Conversation
… not retrieve RTF that lacks a null terminating character
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## release/10.0 #14527 +/- ##
======================================================
+ Coverage 77.10887% 77.10915% +0.00028%
======================================================
Files 3273 3273
Lines 645062 645083 +21
Branches 47704 47708 +4
======================================================
+ Hits 497400 497418 +18
- Misses 143986 143989 +3
Partials 3676 3676
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
@SimonZhao888 For backport PRs, screenshots are not required, however, the "Test methodology," "Regression," and associated issues sections must be filled out in detail. Please refer to the PR #14121. |
KlausLoeffelmann
left a comment
There was a problem hiding this comment.
Looks good to me - approved.
One thing, though:
We should add (as a follow-up PR, not in the context of this one) one additional test, where we test RTF with a terminator to establish, that the existing behavior really remains.
Backport #14461 to release/10.0
Fixes #14458
In ReadStringFromHGLOBAL method requires a null terminator to determine string length. The format dispatch switch groups RTF (a registered format) with CF_TEXT and CF_OEMTEXT (standard formats), routing RTF through this null-termination-required path.Composition.NativeToManagedAdapterReadStringFromHGLOBAL()
When external applications (PowerPoint, etc.) place RTF on the clipboard without a null terminator — which is valid per the Windows clipboard spec — the method returns instead of the actual RTF content.string.Empty
Proposed changes
Customer Impact
Regression?
Risk
Test methodology
Microsoft Reviewers: Open in CodeFlow