html links no longer copy to the windows clipboard properly

[tonyheller]

As of December 20, 2021, when links are copied as html on Windows 10 - the Windows clipboard no longer recognizes them as html links

For example, if an html link is created for this web page
https://tidesandcurrents.noaa.gov/sltrends/globalregionalcomparison.html

And then I paste it into the WordPress editor, it appears like this :

The code which is getting embedded as html now (incorrectly) looks like this

The pasted link used to appear in the WordPress editor (correctly) as a link :

[pdbub]

This also happens on Mac OS 12.0.1 and Chrome OS. At least since 0.5.1 or so. (Now on 0.5.5 and still happens.)

[dckc]

likewise on linux (Ubuntu 18.04, brave) pasting into google docs.

I'm more or less addicted to this feature. I'm open to contributing financially to see it restored. I started exploring a bounty on bountysource. Do let me/us know if that's of interest.

[tonyheller]

I'm guessing the problem occurred in this recent change by ku. If I had permissions to work on the project I could probably fix it fairly quickly

[dckc]

... If I had permissions to work on the project I could probably fix it fairly quickly

permission? I don't understand. It's open source. What permission would make any difference as to whether you can fork it and make a pull request?

[patkujawa-wf]

@ku I'm guessing something to do with changing what's in the clipboard has lost the html version of the clipboard contents which is what enables rich link pasting. Do you know where the fix might be? It's been a while... :)

[patkujawa-wf]

Another oddity is that the contents of content.js don't seem to match what's in the repo in master 😕

chrome.runtime.onMessage.addListener(function (request, sender, sendResponse) {
  switch (request.type) {
    case 'ping':
      return sendResponse({type: 'pong'})
    case 'showInputDialog':
      const text = window.prompt("CreateLink needs your input");
      return sendResponse({type: request.type, text});
    case 'selectedText':
      const s = document.getSelection()
      return sendResponse({ type: request.type, text: (s ? s.toString() : '')})
    case 'evaluateFilter':
      const f = new Function('s', request.code)
      return sendResponse({ type: request.type, text: f.call(null, request.string)})
    case 'copyToClipboard':
      return sendResponse({ type: request.type, text: copyToClipboard(request.link) })
  }
});


function copyToClipboard(text) {
  // it does not copy the text to clipboard if it's hidden completely by "display: none".
  const textarea = document.createElement('textarea')
  textarea.setAttribute('style', `
        position: absolute;
        width: 0.1px;
        height: 0.1px;
        right: 200%;
        opacity: 0.1;
      `)
  textarea.setAttribute('id', 'clipboard_object')
  document.body.appendChild(textarea)
  textarea.appendChild(document.createTextNode(text))
  textarea.select()
  document.execCommand("copy");
  textarea.parentNode.removeChild(textarea)
  return text
}

I would have expected something looking more like copyToClipboard. Perhaps the package needs to be rebuilt?

[patkujawa-wf]

Running it locally, I do see even with the latest code that it's falling back to creating a textarea and copying that due to Clipboard API failed DOMException: Document is not focused.:

Note that based on https://stackoverflow.com/questions/56306153/domexception-on-calling-navigator-clipboard-readtext I also tested without the js console open and the same exception is logged.

[patkujawa-wf]

Looks like @ku is fixing things. Perhaps 9270657 fixes?

[patkujawa-wf]

Upgrading to the latest fixes it for me.

[nodchip]

In my environment, the version 0.5.7 still copies as a plain text. The steps to reproduce is below:

1. Install Create Link from Chrome Web Store. https://chrome.google.com/webstore/detail/create-link/gcmghdmnkfdbncmnmlkkglmnnhagajbm
2. Restart Google Chrome.
3. Go to https://github.com/ku/CreateLink
4. Click the Create Link icon.
5. Select HTML.
6. Create a Google Docs document.
7. Paste on the document.

[patkujawa-wf]

I think what's going on is that it falls back and fails if the focus isn't on the page itself. I always use a keyboard shortcut and as long as I click inside the webpage first, it works. But I was also able to reproduce it failing by clicking on the extension icon. It also fails with the keyboard shortcut when the URL/address bar is focused (rather than the webpage itself).

[dckc]

it's baaaack!

these symptoms, that is

#41 suggests I'm not the only one seeing this.