Plugins incompatibility: File Highlight and Copy to Clipboard

Information:

• Prism version: [1.16.0]
• Environment: [Browser]

Does the latest version of Prism from the download page also have this issue? Yes.

Description The plugin Copy to Clipboard works well if the code is sourced between the <pre><code> tags. On the other hand, if the code was sourced using the File Highlight plugin, e.g.

<pre data-src="/path/to/asset" class="language-shell" data-download-link="" data-download-link-label="download"></pre>

… then Copy to Clipboard fails. Instead of copying the code, it simply copies Loading…, which interestingly, is what initially appears when File Highlight is still loading the code from the file.

Example Here is a sample webpage that shows this incompatibility: https://www.majlovesreg.one/adding-brotli-to-a-built-nginx-instance.

[RunDevelopment]

Interestingly, your website works flawlessly in the best of all browsers: IE11.

[RunDevelopment]

Alright, after a few hours of debugging your website, I finally found the answer! ^_Yaaaaay

TLDR;

Don’t load the script containing Prism asynchronously until this is fixed.

The long version

File Highlight and Copy to Clipboard are not incompatible. In fact, the plugin page of Copy to Clipboard uses File Highlight to load the code which is then can then be copied. (You can’t see the copy button because of an issue of Toolbar and the Prism page design (will be fixed soon). In the meantime, setting right: 10em for div.code-toolbar > .toolbar in the dev tools of your browser will make the button visible.)

The problem is that File Highlight has to executed after the initial Prism.highlightAll because the FH will insert a code element with the text Loading… inside all pres with a data-src attribute. If FH were to be executed before Prism.highlightAll, all of the Loading…-code-elements would be highlighted as well (which is not intended) only to highlighted again after the code has been loaded. One of the consequences of this double-highlighting is that all plugins are run twice on the code element. Most plugins check for multiple executions on the same element, so this usually isn’t a problem but it is in this case because the text content of the code elements changed from Loading… to whatever code has been loaded. This is the reason why the copied text was Loading…: The Copy to Clipboard plugin also detects these multiple executions on the same element.

Then why was File Highlight executed before Prism.highlightAll in the first place? Events. This is the code which adds FH’s callback and this adds the Prism.highlightAll callback. If the Prism script is loaded synchronously, both FH and highlightAll use the DOMContentLoaded event. Because Prism Core is always loaded before FH, the FH listener will be executed after the highlightAll listener, so no problem. But if the Prism script is loaded asynchronously, the DOMContentLoaded event might have already been fired, so we use requestAnimationFrame (or setTimeout) instead. The problem here is that just because document.readyState !== "loading" doesn’t mean that the DOMContentLoaded event has been fired because there is the interactive ready state. So what happens is that highlightAll uses requestAnimationFrame and gets executed before FH which uses DOMContentLoaded.

Depending on how you look at it, the bug is either that File Highlight doesn’t use the same async logic as Prism Core or that the async logic of Core doesn’t quite work.

Thoughts? @mAAdhaTTah @Golmote.

Btw. #959 added Prism Core’s async logic.