Upgrade or patch Penpal to avoid plugin message latency

[Convincible]

datocms-plugin-sdk 2.2.5 resolves Penpal 4.1.1.

This version of Penpal inherently produces an issue that can compound to plugins exhibiting significant/visible input lag.

In Penpal 4.1.1, its steady-state call and reply handlers access event.data before validating event.source and event.origin. In Chromium, qualifying cross-origin messages can consequently trigger expensive deserialisation in every plugin iframe. In our traces, these receivers averaged roughly 5–6 ms per callback and caused noticeable typing latency.

The issue appears resolved in Penpal 7+, however I appreciate that upgrading to that isn't trivial.

Our own solution is to maintain a local patch that checks source and origin before accessing data. This removed the associated V8.DeserializeIsolate and V8.DeserializeContext work, reduced average receiver time to under 1 ms, and improved typing lag enormously.

The general resolution would be either to:

• migrate to the newer Penpal version; or
• apply an equivalent patch in the SDK

[roger-datocms]

This is a really great find, BTW (and a precise fix)... thank you!

@stefanoverna this person deserves an award ^

(Edit)

In Chrome/Chromium, as a timing attack prevention, it will deliberately slow down untrusted cross-origin messages that are >= 16 KB. When Penpal's older version that we're on deserializes event.data before accessing event.origin, it is still considered untrusted, so Chrome forces it to go through slow_mode and repeats the deserialization 4-8x to mask its real duration.

This is especially expensive for us because we send the whole ctx on every host change (sometimes every keystroke), so it's almost always bigger than 16 KB on any realistic record, and the slow down makes deserialization ~7x slower.

The fix is just what the OP suggests, forcing a read on event.origin before we access the data. This can be done in a simple wrapper like:

// Listen at the capture phase before Penpal's bubble phase. Return the value (to nowhere) so this survives some minifications (like Terser's `pure_getters`)
window.addEventListener('message', (event) => event.origin, true); 

That clears the untrusted flag and puts the rest of the event back onto the fast path.

Firefox and Safari do not have this mitigation to begin with, and even if they added one in the future, it should be a safe patch. This is also much lighter than upgrading Penpal in full, or vendoring it with a patch.

We can also add this same mitigation on the host side, in the CMS's Penpal.

[roger-datocms]

@Convincible This (and the other fixes) are undergoing testing right now, so hopefully it won't be much longer.

But I wanted to clarify something about this particular bug: What (user-facing) situation are you noticing the input lag in? In my tests, this patch DOES significantly speed up the message sending... BUT, there may be other things (e.g. some downstream deserializer, maybe Structured Text validation & parsing) that are also slow, that this patch wouldn't touch.

In other words, this patch may indeed fix a latent bug and help a bit with input performance, but it may not alone be sufficient. The difference I could measured was a few tens of milliseconds, which normally should not cause too much user-facing latency on its own.

Can I see the actual record that's laggy for you (or can you post a JSON of its CMA record contents, sanitized as necessary, and/or a screen recording) so I can try to replicate it more precisely? If it's private, feel free to send it to me at r.tuan@datocms.com.

If it's not directly related to Penpal and the plugins SDK, it may require a separate patch (outside of this batch), but I'll take a look and report it for you separately if needed.

Otherwise, I'll let you know once this batch of fixes goes live. Hopefully really soon!