Fixes Portable Text editor data issue and contrast for comments

We have identified a bug shipped in v6.9.2 in the Portable Text Editor for Sanity Studio that could cause data-loss. We have deprecated v6.9.2 through v6.14.0 on npm. We strongly recommend you to upgrade your sanity dependency to v6.14.1, and bump or remove any @portabletext/editor dependency-overrides to v8.1.5:

npm upgrade sanity

The Studio’s array field handler (Portable Text is essentially an array of objects) checks every block deletion against its own cached copy of the field value. If the delete would empty the array, it unsets the whole field instead of just removing one block, leaving an empty array ([]).

Usually, if you delete a block from a field whose cached value has caught up and nothing goes wrong, because the cached copy still holds the other blocks. But in a field that started empty and filled up fast, the check can see an empty array while the editor holds several blocks, and the Studio would send an unset(["blocks"]) patch.

If the editor doesn’t know that the field is unset, then later keystrokes would go out as patches against block keys the server no longer has, and the API would accept them and apply nothing. The editor keeps rendering the content, but it would not be the saved. Causing work to disappear once someone navigated away from the document.

The Mutation API accepts these changes by design. A patch for blocks[_key=="x"] is a query, and in a collaborative editor a patch often arrives just after someone else delete what it targeted. Matching against nothing is a excepted race, and since transactions are atomic, erroring out would let one late patch roll back a batch of legitimate edits. What the API can’t tell was a race condition from a client destroying its own field.

Until v6.9.2, the Portable Text Editor would reset itself the moment the field emptied, so you saw the loss within second of causing it, and would be able to undo the unwanted change.

v6.9.2 included an dependency update that brought @portabletext/editor up to v7.10.16, which fixed real bug in how the editor handled empty-to-empty updates, but stopped treating them as a remote change, thus not reseting the editor on the empty field condition anymore. We ended up fixing one bug, but unintentionally causing another.

This version ships a fix for this and bumps @portabletext/editor up to v8.1.5 (remove any overrides to this dependency if you have them). The fix in the studio is to skip the last-item-removal rewrite for arrays-of-object fields so the destructive unset(["blocks"]) never gets sent.

We are taking extra steps on the backend to avoid similar bugs from happening in the future.

To anyone who was affected by this bug, we are sorry.

• Fixes parts of the Studio, including the comments UI, that followed the OS color scheme instead of the appearance selected in the Studio user menu. The Studio now pins the document to its resolved appearance, including when the hosting application's bundler has down-leveled light-dark().