Re: PSA: HTML fragment mode interaction between Chromium, Clipboard & Notepad++

On Tue, 2/10/2026 7:17 AM, Maria Sophia wrote:
> PSA: HTML fragment mode interaction between Chromium, Clipboard & Notepad++
> 
> There is a confusing interaction between Chromium-based applications when
> copying to the Windows clipboard and then pasting into Notepad++ that can
> break basic editing functions like Select All (Ctrl+A).
> 
> What happens is the following sequence:
> a. You copy Chromium-based text (Ctrl+C) to the Windows clipboard
> b. You paste that into Notepad++
> c. You try to select all (Ctrl+A)
> What happens is the selection flashes, but nothing is selected
> If you add a blank line at the top, then Ctrl+A works as expected.
> 
> It took me a long time to track this very repeatable artifact down, so I am
> sharing the explanation here for anyone else who runs into it.
> 
> When you copy text from any Chromium-based application, Apparently Windows
> does not just copy plain text. Windows actually puts two versions of the
> text on the Windows clipboard:
> 1. a normal plain-text version
> 2. a hidden HTML-formatted version
> 
> This apparently happens with Chrome, Edge, Brave, Vivaldi, and many
> Electron apps such as Slack, Discord, and VS Code.
> 
> When we paste that clipboard data into Notepad++, Notepad++ sees the hidden
> HTML version and Notepad++ assumes the paste is part of a larger HTML
> fragment. That puts Notepad++ into a strange internal state, which is
> apparently sometimes called "HTML fragment mode".
> 
> In this mode:
> a. Ctrl+A will not select the whole document
> b. Therefore, Ctrl+X will not cut anything
> c. Because the Ctrl+A selections are behaving incorrectly
> 
> What took me a while to figure this out was that this artifact has nothing
> to do with the text itself so a hex editor does not show the artifact.
> 
> It is simply how Notepad++ reacts to the Windows clipboard format used by
> Chromium-based applications.
> 
> The workaround I've come up with is surprisingly simple: a. Insert an extraneous leading blank line at the top of the document
> b. Now when you press Ctrl+A, the selection works as expected
> c. Copy (Ctrl+C) or Cut (Ctrl+V) the selected text, as desired
> d. Then delete the extraneous leading blank line
> 
> That tiny change of the extraneous blank line apparently forces Notepad++
> to abandon HTML fragment mode and treat the text as normal again.
> Q: Why does deleting the blank line work around this issue successfully? A: Because the hidden HTML fragment boundary is treated as if it were
>   the first line of the document. Deleting the first line removes that
>   invisible boundary and resets the buffer.
> 
> Summary:
> A. Chromium apps (apparently) copy hidden HTML to the clipboard.
> B. Notepad++ sees that artifact and enters HTML fragment mode.
> C. There is no indication whatsoever you're in HTML fragment mode!
> D. But in that mode, Ctrl+A stops working correctly.
> E. Yet, inserting a blank line resets Notepad++ back to normal.
> 
> If you have ever pasted something into Notepad++ and wondered why you
> suddenly cannot select or cut the text, this artifact might just be why.

As I understand it, the Clipboard can have multiple representations
on it at one time. Sometimes a person pastes into Notepad.exe and
then copies a text again, as a means of "cleaning" any multi-item
clipboards.

What you need in hand, is a clipboard viewer, to see what is on offer
and what Notepad++ may have accessed as its choice. So far, I have not
spotted the "perfect" chunk of code for this.

*******

https://stackoverflow.com/questions/35827764/how-to-know-the-type-of-data-in-clipboard-through-python

import win32clipboard as clipboard                    # Example in Python, version unknown
def getTheClipboardType():
    formats = []
    clipboard.OpenClipboard()
    lastFormat = 0
    while True:
        nextFormat = clipboard.EnumClipboardFormats(lastFormat)
        if 0 == nextFormat:
             # all done -- get out of the loop
             break
        else:
             formats.append(nextFormat)
             lastFormat = nextFormat
    clipboard.CloseClipboard()
    return formats

Example output:
[13, 1, 49427, 49953, 49422, 49304, 16, 7]

*******

Whereas the "Windows way" is to "ask" for a format, without
enumerating what formats are available.

*******

Here is the "Hah!" moment.

https://learn.microsoft.com/en-us/windows/win32/dataxchg/clipboard-formats

   "A window can place more than one object on the clipboard, each
    representing the same information in a different clipboard format.

    Users need not be aware of the clipboard formats used for an object on the clipboard. <=== Hah!
   "

   "To find out how many formats are currently used on the clipboard,
    call the CountClipboardFormats function."

There is your problem definition.

If you "copy" three files in Explorer file manager, then
three items of "filesystem" type or so, are on there. Notepad++
should not respond to such a clipboard format. But it is possible
to extract the text strings from that.

   Paul