RC4 - Scrivener HTML clipboard not recognized in Chromium-based browsers. Plain text only.

Scrivener Windows Beta (Archived)
1

Hi - Scrivener’s HTML clipboard is not being picked up in the major Chromium-based browsers in RC4.

This means that when we copy some text from our Scrivener pane and paste into Google Docs, we’ll lose or retain formatting depending on which browser we’re using. :confused: We’ll paste plain text if we’re using Chrome, Edge or Opera, and paste formatted text if we’re running Firefox. Same result when pasting into WordPress’s WYSIWYG editor, or that of any other content management system.

To test for yourself without firing up Docs or a CMS, try the public demos of these three javascript-based WYSIWYG editors. Nothing to download; they’re ready to go in your browser:

TinyMCE: tiny.cloud/docs/demo/basic-example/

CKEditor: ckeditor.com/ckeditor-4/demo/

Summernote: summernote.org/

Try copying some formatted text, bold, italic, colors, headers, from your Scrivener editing pane into these online editors using Firefox and using Chrome. Note that these editors apply some formatting filters of their own – much needed when pasting from Scrivener – so you may see bold but not colors when pasting in Firefox. But in Chrome you’ll see only plain text. I’m guessing the Chromium code is more stringent about the proper formatting of the clipboard, which can be painstaking.

The interesting middle case appears when using the browser in the QtWebEngine embedded in Scrivener itself. To do so, drag the links above into Bookmarks, and view each editor in one Scrivener editing pane while pasting formatted text from the other. Oh yeah, formatting is retained. But then what? When you copy from those editors out to your CMS, you’ll lose the formatting again, unless you actually maintain said CMS in that Scrivener web-rendering pane or in Firefox.

Moreover, at least one other QtWebEngine-based application has the same behavior: PageEdit 1.20, the editor under development as a standalone component of Sigil. It’ll cheerfully paste formatted text to and from Scrivener, from the above scripts loaded in Scrivener’s browser, and from Firefox. But pasting from PageEdit into Chrome will yield only plain text.

So this is a Qt problem. But Scrivener users will be experiencing and raising it.

As a workaround for those of us who would stick with our browser of choice, we can paste first into the Gecko-based editor BlueGriffon, or into an email in Thunderbird, then copy and paste on into Google Docs or our CMS.

I also have an AutoHotkey fix that uses a street-tweaked version of the WinClip tool originally developed, I believe, by Apathy Softworks. Using WinClip.ahk and WinClipAPI.ahk from this page:

autohotkey.com/boards/viewt … =6&t=29314

…with the tweaked version of GetHTML() from here:

autohotkey.com/boards/viewt … 22#p308322

Then subroutine be like:

ClpChr:
rawhtml := WinClip.GetHTML()
startpos := instr(rawhtml, "<!--StartFragment-->")
rawhtml := substr(rawhtml, startpos)
WinClip.Clear()
winClip.SetHTML(rawHTML)
Msgbox, HTML Clipboard patched by WinClip
Return

For experienced developers only! Maybe the script can help reveal the critical difference in the Chromium-incompatible clipboard.

Rgds - Jerome

2

Awesome write-up!

3

Thanks Jes. This is life under lockdown. :neutral_face:

4

I’m one of the “essential” IT guys for the college I work for. Only one day so far for work-from-home since the lockdown started and 30+ hours of overtime. Leaves next to no time for writing or doing proper testing of personal-use beta software. :frowning:

5

Hi - Output from a test script confirms that Scrivener structures its HTML clipboard quite differently from the formats recognized by the Chromium browsers:

  • The HTML clipboard formats use offset values to identify the beginning of the document tree (StartHTML:nnnn) and the beginning of the clipped fragment (StartFragment:nnnn).

  • In all the HTML clipboards recognized by Chromium browsers, the StartFragment pointer lands after the <body> element.

  • In the Scrivener-rendered clipboard, the StartFragment pointer lands before the <html> element.

Clipboards from Firefox, Chrome, Edge and WinClip, all recognized by Chromium browsers, are described as Version 0.9. Clipboards from Scrivener, PageEdit and LibreOffice are described as Version 1.0. Of these, only LibreOffices’s is recognized by Chromium browsers, and StartFragment and EndFragment pointers again land directly within the tags. It makes sense to separate the formatted text content from the scripts and stylesheets that are loaded between and .

Here are representations of the HTML clipboards I’ve tested. The actual formatted text content is removed, so the offsets shown are not accurate, but where StartFragment and EndFragment point within the document tree is the key to Chromium compatibility.

--------------------------------------
(Paste from HTML page in Scrivener, or from PageEdit by Sigil. Formatting not recognized by Chromium browsers)
Version:1.0
StartHTML:0000000107
EndHTML:0000003615
StartFragment:0000000127
EndFragment:0000003597
<!--StartFragment-->Text Content<!--EndFragment-->
--------------------------------------
(Paste from Doc in Scrivener. Formatting not recognized by Chromium browsers)
Version:1.0
StartHTML:0000000107
EndHTML:0000000932
StartFragment:0000000127
EndFragment:0000000914
<!--StartFragment--><?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
	<meta charset="utf-8"/>
  <meta name="Generator" content="Scrivener for Windows HTML Writer">
  <meta name="ScrivenerVersion" content="2.9.9.5">
	<title>Untitled</title>
</head>
<body>
Text Content
</body>
</html>
<!--EndFragment-->
--------------------------------------
(Paste from Firefox, Chrome, Edge, WinClip. Formatting recognized by Chromium browsers.)
Version:0.9
StartHTML:00000234
EndHTML:00000707
StartFragment:00000268
EndFragment:00000671
SourceURL:https://sample.com
<html><body>
<!--StartFragment-->Text Content<!--EndFragment-->
</body>
</html>
--------------------------------------
(Paste from LibreOffice Writer. Formatting recognized by Chromium browsers.)
Version:1.0
StartHTML:0000000168
EndHTML:0000000999
StartFragment:0000000808
EndFragment:0000000982
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
	<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
	<title></title>
	<meta name="generator" content="LibreOffice 6.4.2.2 (Windows)"/>
	<meta name="created" content="00:00:00"/>
	<meta name="changed" content="00:00:00"/>
	<style type="text/css">
		@page { size: 8.5in 11in; margin: 0.79in }
		p { margin-bottom: 0.1in; line-height: 115%; background: transparent }
		a:link { color: #000080; so-language: zxx; text-decoration: underline }
		a:visited { color: #800000; so-language: zxx; text-decoration: underline }
	</style>
</head>
<body>Text Content
</body>
</html>
--------------------------------------

In my view, the surest way to create an HTML clipboard recognized by Chrome is to emulate the clipboard generated by Chrome.

Rgds - Jerome

6

Thanks for the detailed write up! I’ve filed this as something to look into once 3.0 is out the door; as you noted, if the issue is how Qt is populating the clipboard, we may be limited in making changes that would make the contents more Chromium friendly, but we’ll see what can be done.

7

I have seen other Qt 5 applications that don’t have this issue, so I’m not convinced it’s a bug with the capabilities of how Qt is populating the clipboard so much as not having the right function call or formatting on the data being written.

At any rate, I would respectfully request that this is a big enough issue (now that Microsoft is pushing their Chromium-based Edge browser as the default on Windows 10, and given Chrome and other Chromium-based browsers’ market share) that it should be considered a show-stopper for release and at least some immediate priority be given to researching and fixing this bug ASAP. Not being able to reliably paste formatted text into the default system browser does not give good optics for the perception of Scrivener for Windows 3.0 being a reliable, stable release.

8

Devin, I have to agree. Scrivener is superbly well thought out and suitable, as designed by a writer, not a programmer or a committee. We can all understand L&L’s imperative to ship Win V.3., and I don’t want to sound like I’m caviling about how long the development process has taken.

But…since the beta process will be entering its fourth year in the week ahead, and since V1 has been the only paid Windows release over ten years (counting its own beta time), does L&L really want to explain to a purchaser of Win V. 3, who wishes to write in Scrivener and paste the writing into her blog, that a brand new production release of Scrivener is going to strip out her links? I can’t imagine the Mac version does. This is kinda what betas are for. The blog may be a review. Scriv users are persons of influence, and first impressions count for a lot.

Rgds - Jerome

9

Facing that problem now. Couldn’t agree more.

Links sometimes get lost pasting into Scrivener as well, depending on the paste method.

Thomas

10

Just for another point of view. I post into my content management system articles each month and have done so for many years. It never even occurred to me to paste and expect the results to be right! But I’m old. I export to text and then format everything and set all links in that system.

11

In the event anyone sets out to address Scriv-Windows’s difficulties in writing to the HTML clipboard, please note that two vital words were stripped in the conversion to Discourse, as I had posted them originally within angle brackets. The cited points should read:

  • In all the HTML clipboards recognized by Chromium browsers, the StartFragment pointer lands after the (BODY) element.
  • In the Scrivener-rendered clipboard, the StartFragment pointer lands before the (HTML) element.

Rgds - Jerome