Apply Clusterize spacer heights via CSSOM so CSP cannot drop them

[brianwarsing]

Summary

Fixes the task-log flickering reported in
Shopify/continuous-deployment#2208:
output streams fine, then flickers, then stops updating, sometimes disappearing.

Reported 2025-10-29 against Shipit, open since 2025-11-06.

#gsd:48220

Root cause

renderExtraTag sets tag.style.height on a detached node and returns tag.outerHTML.
insertToDOM joins those strings and html() assigns them with innerHTML, so the height
reaches the document as a style attribute parsed from markup:

// vendor/assets/javascripts/clusterize.js
renderExtraTag: function(class_name, height) {
  var tag = document.createElement(this.options.tag), ...
  height && (tag.style.height = height + 'px');   // detached
  return tag.outerHTML;                            // -> serialized to markup
}

Under a style-src policy without 'unsafe-inline', browsers refuse to apply such an attribute.
Shipit serves exactly that policy:

$ curl -sI https://shipit.shopify.io/
content-security-policy: ... style-src 'self' https:

So the spacers render at height 0. Total scroll height collapses to just the rendered cluster
regardless of how many rows exist, scrollTop is clamped into that range, getClusterNum()
derives a different cluster from the clamped value, insertToDOM swaps in different rows, and the
height changes again.

The console fills with Applying inline style violates the following Content Security Policy directive: "style-src 'self' https:".

Measured

Shipit's task page with the real assets under the verbatim production CSP, 10 seconds at 1
line/sec:

	without CSP	with CSP	with CSP + this fix
html() swaps	10	601	14
re-entrant swaps	0	145	0
repaints/sec	~8	83	~8
scrollHeight at 800 rows	19316	4844	19316
first visible line number	236 237 238 239 …	173 173 239 173 242 173 …	236 237 238 239 …

The viewport alternates between two regions of the log roughly eighty times a second.

Two details that match the bug report precisely:

• Below rows_in_block no spacers are emitted, so the page starts out fine and only degrades
  once the log grows — matching "start out fine, but soon begin flickering".
• The only_bottom_offset_changed fast path already uses lastChild.style.height on a live
  node, which CSP permits. That asymmetry is why the failure presents as oscillation rather than a
  static break.

The fix

CSSOM writes are not blocked by CSP — only markup-parsed style attributes and inline <style>
elements are. Verified under the policy above:

how the height is applied	rendered
detached node → outerHTML → innerHTML (current behaviour)	0px
el.style.height on an inserted node (CSSOM)	500px
<style> element injected at runtime	0px

So carry the height through the markup round trip in a data attribute and apply it via CSSOM once
the nodes are live. 15 lines, confined to the vendored library.

Alternatives considered

• Add 'unsafe-inline' to style_src. Works, but weakens the policy application-wide to
  accommodate one 2016 vendored library, and reverts a posture that was deliberately tightened.
  Grepping every engine asset, this is the only real offender.
• Add style-src to content_security_policy_nonce_directives. Does not help — nonces apply
  to <style> elements, not style attributes.
• Upgrade Clusterize. Unmaintained since 2018; upstream still contains the same code.

Testing

The engine has no browser/system test harness, so this cannot be covered by the existing suite.
It was verified in a standalone rig that loads the real compiled assets, serves the verbatim
production CSP, and emulates TasksController#tail byte-for-byte. Detection is a
requestAnimationFrame sampler recording the first visible line number each frame; flicker is
that sequence moving backwards while scroll position does not.

Happy to attach the rig or a screen recording if useful.

Co-authored-by: AI (Pi/anthropic/claude-opus-5) noreply@pi.dev