HTML editor behaves unpredictably at non-default browser zoom levels [edit: corrected title; bug is about TinyMCE HTML editor, not Structured Text]

🆘 Support
,
1

Hi DatoCMS team,

We recently came across an issue similar to the one reported here:

However, we’ve noticed some additional, seemingly related issues. After troubleshooting across different users, machines and browsers, we found a strong connection between these behaviours and non-default browser zoom levels.

What we’re experiencing

At certain zoom levels:

  • Pasted text sometimes becomes bold, even when the source text isn’t bold.
  • Newly typed text can also unexpectedly become bold, so the issue isn’t limited to copy/paste.
  • The Structured Text toolbar consistently collapses into a ... menu, with the formatting controls appearing in a popover over the editor content.
  • Occasionally, DatoCMS incorrectly shows the “Take over” state, as if the same record were open in another tab/window, even when it isn’t.

The toolbar issue is consistently reproducible at affected zoom levels. The unexpected bold formatting and “Take over” state are more intermittent, but we have never observed any of these issues at the default zoom level.

Zoom & browser testing

We initially couldn’t reproduce the issue on another machine, even with the same DatoCMS user, browser and browser version. Eventually, we discovered that the behaviour only seems to occur at non-default browser zoom levels.

For example:

  • One Mac: reproducible at around 67%
  • Another Mac: reproducible at around 75%
  • Default zoom: no issues observed

We’ve also tested across browsers on macOS:

  • Chrome: reproducible
  • Firefox: reproducible
  • Safari: unable to reproduce

We also tested Incognito mode and different window sizes, so the issue doesn’t appear to be related to browser extensions, cached state, or simply the window width.

Interestingly, the screenshot in the previous report linked above also appears to show Chrome’s non-default zoom indicator in the address bar, so we wondered whether browser zoom might have played a role there as well.

Because the bold formatting and “Take over” issues are intermittent, they’ve been difficult to capture reliably in a recording. The toolbar behaviour, however, is consistently reproducible at the affected zoom levels.

Happy to provide screenshots, console output, or exact browser/macOS versions if helpful.

Thanks!

2

Hi @technology,

Thank you for this detailed report!

This bug seems entirely plausible, perhaps as a breakpoint-dependent mechanism — maybe our UI thinks you’re switching to and from the mobile view and recreating some React components incorrectly, based on the calculated viewport size after a zoom?

However, it’s not something I have been able to easily replicate on my side :frowning: Would you be able to provide a screen recording or two, please? You can send it to us at support@datocms.com, or use this service: Send DatoCMS a screen recording

I suspect it has something to with the combination of not just browser zoom, but maybe also things like:

  • The nodes before/after what you’re pasting
  • Whether there’s any sort of formatter currently “primed” at the cursor when you paste
  • The clipboard format of whatever you’re pasting (plaintext, Markdown, rich text, HTML, etc.)
  • Whether you’re in focus mode
  • Whether the left/right sidebars are open

Anyway, seeing an exact reproduction (or several, if you are able to!) would really help me isolate the actual bug and be able to replicate and report it to the devs most effectively.

It is interesting that this is reproducible on Chrome and Firefox but not Safari… maybe webkit handles something differently there, but I don’t yet know what exactly. Regardless, the screen recording would really help so I can try to reproduce the conditions exactly.

Thank you again, and sorry for the inconvenience here!

4

Hi roger, thanks for looking into this!

We’ve done some more testing since the original report and have been able to separate the different behaviours a bit more clearly. We’ve also sent three short screen recordings to the support email address showing the issues below.

Bold text on paste

At the moment, we can only reliably reproduce this when copying from Google Docs, although earlier we were also able to trigger unexpected bold formatting from other sources and even while typing directly into the editor.

Interestingly, with Google Docs it currently seems to happen only when copying a short piece of text. When copying a longer section, the pasted text wasn’t bold. This can be seen in the recording as well.

“Take over” / “Recover”

We can reproduce the “Take over” state after refreshing the page.

After taking over, clicking “Recover” doesn’t appear to do anything — the button remains visible and the state doesn’t seem to change.

Collapsed ... toolbar

This one seems much more consistently tied to a specific browser zoom level.

On my 14" Mac, it occurs at exactly 67% browser zoom, not above or below it.

Our content team, who originally reported the issue to us, can reproduce it at 75% zoom on their machine.

As shown in the recording, at the affected zoom level the issue also makes editing particularly difficult: when clicking into the input field to select/edit text, the toolbar popover opens immediately and overlays the content, preventing us from selecting the text normally.

Hopefully the recordings make the different behaviours easier to reproduce. Thanks again for investigating!

5

Thank you @technology!

I’ve received all three recordings and they were very helpful. I’m going to create separate bug reports for each of these (because they are separate bugs, even though two of them affect TinyMCE). I’ll report back on each as they’re addressed.

First off, the zoom bug affecting TinyMCE (the HTML editor, not Structured Text). Confirmed on Firefox and Chrome and reported to our devs. Doesn’t happen on Safari except on extreme zoom levels. Workaround for now: Use TinyMCE’s full-screen edit mode, which makes the edit box much bigger and doesn’t have this same weird collapsing behavior. (But full screen is broken on Safari right now; will report that separately).

I’ll work on the other two bugs ASAP!

7

The bold-on-paste bug: That’s actually a long-standing Google Docs bug :person_facepalming: They produce invalid HTML on copy. Google is unlikely to ever fix it, unfortunately, and many text editors suffer from it… it produces markup like this, even for that plaintext string:

<b style="font-weight: normal"
  id="docs-internal-guid-08817a0f-7fff-5a2b-a024-9186058c4d69"><span style="
        font-size: 11pt;
        font-family: Arial, sans-serif;
        color: #000000;
        background-color: transparent;
        font-weight: 400;
        font-style: normal;
        font-variant: normal;
        text-decoration: none;
        vertical-align: baseline;
        white-space: pre;
        white-space: pre-wrap;
    ">MDN is an open-source</span>
</b>

We had actually to make a workaround for it for Structured Text… see details in that other thread: Structure Text editor does not copy/paste styles anymore - #8 by roger (note that this is actually Google’s bug… we just make a workaround, like all the others mentioned in that link had to do too… because nobody at Google cares enough to fix this, sigh)

I’ll ask the devs if we can make a similar workaround for TinyMCE (the HTML editor you’re having trouble with).

Interim workaround: Don’t copy from Google Docs, or paste it without formatting. Or paste it into another word processor first, and then copy THAT word processor’s output into Dato. Or use Firefox (which cleans up the Google Docs HTML on copy, bypassing Google’s bug).

8

The recover/takeover bug: Does it happen when you don’t refresh the page right after saving? Is there a reason you’re doing that to begin with?

The takeover situation is different from the record content. It just means that somebody else is editing the page at or around the same time. In your video, it looks like you saved the recorded and then immediately reloaded it before the old session could time out, so it looks like you’re “conflicting” with your own edit sessions… but because you didn’t change anything else, it was just a false-positive.

The intent there is meant to warn you when someone else (or you, yourself, in a different browser or browser tab) is working on the same record, so you don’t risk losing edits.

My guess is this probably happened while you had multiple tabs (or different browsers) open on that page trying to replicate the zoom and bolding bugs.

If you don’t see it unexpectedly while working normally, it’s not an issue… you can just ignore it. It’s really only meant to warn you when someone else is working on a record so you don’t override their changes without taking it over on purpose.

If there’s an actual recover bug (where you had data that was supposed to be there, but it couldn’t successfully recover it), let me know, but otherwise this one seems like a temporary side effect, maybe, of the other testing?

9

Hi roger,

thank you so much for the detailed explanation and for looking into all of this, really appreciated!:folded_hands:

We did some more testing around the Take over warning, and can reproduce it with:

  • Changes :right_arrow: Save :right_arrow: Publish :right_arrow: Refresh
  • Changes :right_arrow: Save :right_arrow: Refresh
  • Changes :right_arrow: Refresh

In all cases, DatoCMS was open in only one browser window/tab, so no other session was active from our side.

It’s not particularly disruptive, we just assumed this wasn’t the intended behaviour, as refreshing seems to make the current user conflict with their own previous session. If that’s expected while the previous session is timing out, then all good!

Thanks again for all the help and for checking the Google Docs/TinyMCE issue! :folded_hands:

10

Edit: This is wrong, sorry! See correction in next post below.

Well, technically speaking, I don’t think this was “intended” either way… it’s just a side effect of the way the CMS is set up, coupled with how browsers “work”.

The CMS already self-updates automatically (like when you or someone else edits a record, the changes should automatically show up within a few seconds — we have a background checker that automatically gets notified of new changes within a few seconds, without needing a manual refresh). So when a user forcibly refreshes it immediately after saving, then in essence they’ve created a new “browser session” on top of the old one, and this confuses the system into thinking they have a new “tab” open. The old one eventually closes itself (after a few seconds), but if you save and then immediately refresh, it all happens too close to each other in time for the system to properly tell them apart — it’s an artifact of how web browsers generally work… the lack of statefulness in HTTP, blah blah blah… too much to get into here :sweat_smile:

I’ll check to see if this is maybe something we can add a special edge-case handler for, just to ignore that situation if can detect it (not sure) so it doesn’t create a false warning.

Anyway, the TLDR for now is just that your users shouldn’t need to refresh after saving. (But I totally get the instinct to want to! It’s not always possible to tell when a system does or does not correctly self-update after a save…). If they’re doing this for any particular reason, like if they don’t “trust” the page to be correct after an update… let me know their particular concern and I can forward it to our UX person to see if maybe we can make it more obvious somehow that “yep, this indeed saved correctly, you don’t have to refresh!”

And no prob on those! I’ll report back as soon as we can fix those.

11

Wait, sorry (on the topic of the self-takeover)… I might’ve spoken too soon!

Claude actually found a potential bug on our side there (related to how we were detecting same-person sessions, and a recent Chrome deprecation: https://developer.chrome.com/docs/web-platform/deprecating-unload). I’ll check that too and report back.

Edit: Yes, sorry, I was wrong on this and the AI was right :sweat_smile:

We already have a special handler for this exact scenario (so users don’t need to take over their own sessions). However, that gradual Chrome deprecation is gradually breaking it.

I’ve prepped a bug fix for this and will let you know once it’s deployed. Sorry about that… should’ve double-checked first before I answered!

12

That takeover issue will be fixed with the next minor CMS version deployment — usually a few days, if it’s not already live.

We’re still working on the others (the TinyMCE issues).

13

Just tested it and can confirm the “takeover” issue is fixed and live! :tada:

You guys rock! Thanks once again for jumping on this so quickly! :raising_hands::heart:

14

I’ve prepped a bug fix for the TinyMCE issues as well, and it’s now awaiting code review (not yet deployed). I’ll let you know once those are live too.