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

Paul wrote:
> There are various "laundering recipes" for fixing issue like that.
> Presumably this Notepad++ behavior has already been noted (somewhere).
> It would be unusual for "bad manners" to go unacknowledged.

I wrote a Notepad++ Macro that "launders" text which is affected since I
needed to copy/paste the text after the macro launders it to pure ASCII.

Apparently when Chromium apps copy text, they don't just put CF_TEXT and
CF_UNICODETEXT on the clipboard. They also include:
a. CF_HTML - a full HTML fragment with metadata
b. HTML Format - a Microsoft-defined clipboard format that includes:
c. StartFragment / EndFragment markers
d. Optional StartHTML / EndHTML offsets
e. And a hidden boundary indicating an HTML document

Notepad++ doesn't render HTML, but it does detect the presence of CF_HTML
and switches into a special internal mode intended for HTML-aware pasting. 

It's invisible because Notepad++ doesn't expose it in the UI, so my simple
brain said "if it's invisible, it's not there" and yet, it was there.

In that mode, Notepad++ treats the invisible HTML fragment boundary as if
it were a zero-width first line. So three things caused me issues.
1. Ctrl+A flashes but selects nothing
2. Ctrl+X does nothing
3. The caret behaves strangely at the start of the document
Because Notepad++ is obeying the HTML fragment metadata.

CF_HTML is not inserted into the document, which is why it never showed up
in the hex editor. It exists only on the clipboard, not in the pasted text.

Manually inserting a blank line forces Notepad++ to reinterpret the buffer
as plain text. The invisible HTML fragment boundary is still there. But the
invisible HTML fragment is no longer at the top of the buffer. Then,
deleting the blank line is forces a reparse of the entire document.

What threw me off the trail was that Notepad++'s internal state changes
based on the clipboard format, not based on the pasted bytes. So the text
looked perfectly normal in Notepad++'s hex editor.

I should re-try Andy's suggestion of Edit > Paste Special > Paste as ANSI
Or use a plugin like "Paste as Plain Text" or use a clipboard cleaner such
as PureText.

For me, the issue was incredibly confusing because:
a. The pasted text looks normal
b. It doesn't happen with Firefox
c. The broken behavior appears random
d. There is no UI indicator that Notepad++ is in HTML fragment mode
Because not only does it only happen when the clipboard contains CF_HTML
but it persists until the buffer is modified in a way that forces a reset.

Now that I know what I know, I can finally modify the shortcuts.xml macro
so that it will consistently convert characters copied from web sites.
-- 
The nice thing about Usenet is you get good ideas from everyone.