XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows   
   From: nospam@needed.invalid   
      
   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-typ   
   -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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)