Presentation Click-to-edit fails consistently on second use, for PortableText fields having only a single paragraph (block)

[narration-sd]

As in the title, the simplest form of this problem shows when you have a PT field with just one paragraph in it. On the web page panel, in the stuudio, you can see its blue outline, click, and the field will be selected properly in the editor panel. But click the page to work on another field, click back on the page for the PT field, and the editor will fail to respond.

On this fail moment, the blue rectangle on the PT field appears to fade, actually a narrower border width I think, which possibly might help to localize the state that's failing. And if you scroll the editor side to the field manually, edits on it will still propagate immediately to the web result, so the data stream is still correct, though some aspect of the map may not be. But the clickability will not recover, so long as there is only the one paragraph in the Portable Text field.

If you use return to add another paragraph, then you can click that in the web page with its own blue border, and it will respond. After that you can click the initial paragraph, and it will have returned to live targeting action, even if you scroll the editor any distance of offset to test, to properly be editing that item. Any other paragraphs willl also be fine, and the field will appear fully click-editable. But once you click off to another field, and try to click back, now the second paragraph you brought life back with has become neutralized, though the first works again.

There are various maneuvers you can use, but this is the core of what happens. If there are two PT fields in the document, one of them single line/paragraph, as in the otherwise nicely performing college news page Astro Presentation was introduced to, the dance between the two can be particularly frustrating.

Overview

These errors reported hide as a 'small' problem, easily overlooked, as arrangements demonstrating it here have seemed to test flawlessly over months, but as will be seen, they are actually a quite serious operational situation for Presentation, to the extent that the issue is indeed in Presentation, as seems quite indicated by details of symptoms.

Whether any or all of the three also-reported React warnings on setup contribute, isn't discernable -- some sense that they may not, but that they could. It appears that VisualEditing book-keeping gets mixed up per PortableText blocks, on Studio or page component sides, less likely by the channel between, but possible. Locating the source of the React warnings should indicate whether what they indicated can contribute to this later failure under normal active Presentation activity.

To Reproduce

Start up a Presentation edit of a document having at least the PT field and one other editable. Perform the sequences just described.

Expected behavior

Presentation should always follow a click on a blue-bordered page PT result with a jump in the editor to the paragraph clicked, as other than in this case, it always does.

Screenshots

I'm providing two movies. One of them shows the primary problem, plus a pair of persistent startup warnings React gives on the Presentation -enabled Studio, which I've traced back to happening with versions at least six weeks ago. The code it reports on seems clearly within the Studio.

The second shows a third React warning, which occurs as the web page starts up in the left pane of a Presentation Studio window, or in a tab of its own. Disabling the Presentation VisualEditing component in the Layout of the web page causes that warning also to cease, and the content is clearly from Presentation, referencing as it does Qbservers and so forth.

However, both of the React warnings occur on startup of the Presentation session -- there are no errors or warnings as the click failures occur.

As these are warnings from React's dev-time version, they disappear on production built use, but the faults with Presentation on PT fields that this issue reports, remain as expected fully occurring, whether or not they have relation to what's warned.

Video of the failure sequences in Presentation, startup-only Studio warnings shown towards end
https://github.com/sanity-io/visual-editing/assets/247945/264565a3-6c97-44bf-a2ef-123678e1ab8d

Video of the VisualEditing-related failure on startup of Presentation-enabled web page
https://github.com/sanity-io/visual-editing/assets/247945/eb800c47-e1ec-4fb0-bbf2-fcef3c0a4c02

Zip of the node_modules/.vite/deps chunk file and map, referenced by errors described and viewable towards end of video:
chunk-QWIXSBWO.js.zip

Which versions of Sanity are you using?

$ sanity versions
@sanity/cli (global) 3.36.4 (latest: 3.43.0)
@sanity/image-url 1.0.2 (up to date)
@sanity/react-loader 1.9.19 (up to date)
@sanity/ui 2.1.11 (up to date)
@sanity/vision 3.43.0 (up to date)
sanity 3.43.0 (up to date)

What operating system are you using?

Windows 11 latest up-to-date, carefully maintained, JetBrains WebStorm running node dev server, most observations in Firefox latest, no differences on Chrome latest

Which versions of Node.js / npm are you running?

$ npm -v && node -v
10.2.4
v20.11.1

Additional context

I brought back code with package versions from as early as six weeks prior, and found all in this report happening the same. So it is not a result of recent slight instabilities surrounding product release.

The same problems, unaffected by pnpm framework and more complex schemas, occur on the college system where they were first discovered. That is not the simpler system demostrating here.

It's probably worth mentioning that the Sanity Astro Presentation provision uses a normal ReactLoader operating in a non-presenting (unless debug set) component on the Astro page, sending its data map and streamed results to Presentation-active React elements behind Astro JSX on the page via nanostore atom.

One factor then is that response is probably faster than with a microcaching system as in NextJs implementations, and response speed can sometimes affect how less-than-sychronized code acts, though what happens here is consistent between fast srerverless (Vercel in college case) and local dev runs which are slower.

Security issue?

No issues in what's disclosed here

[narration-sd]

For Sanity team, I remembered this morning that I've already set up a private repo with the fully implemented Astro Presentation application/Studio, which s exactly the one that you are seeing in the issue and its movies.

It even includes a sample dataset, so you can immediately run it on dev or your preference of deployment.

This was for other purposes at Sanity, so it's already entirely private for you. All I need is your github Id or an email address to invite and thus enable you at Sanity.

All code is visible in this, even the package, so you can rapidly determine if the problem is indeed on the Presentation side, or somehow in how the system is employing it -- fully open mind as always there....

[narration-sd]

Just a note to explain the referenced post just above -- it's because this same problem identically has shown up in a completely different Presentation implementation.

Thus I think you'll find it in all of them, and that this is the place to have lodged an issue so it 'gets well', which am very confident it will. Best fortune on it.

[narration-sd]

An update here, and hope that I may not have slowed down attention, by being too explicit above!

• this bug continues to show always, on up-to-today current versions, and on several applications

• it will absolutely prevent second or later click-to-edit from a Portable Text which has only one block/paragraph, after you've used click-to-edit once

• I had to make an 'unusual' workaround for that, to succeed in a Sanity Proof of Concept for a college Marketing director, enclosing the only-ever-single but rich text paragraph's PT with a presentation-aware div.

• the workaround suffices for the single-paragraph case, but can't for alternate paragraphs in a single portable text

• again, it's a fault that can easily slip through testing, though a test could be devised, but it will certainly show to real content editors, as they won't be able to click-to-edit the previous paragraph they were on -- a fault enterable in several possible ways.

Fully appreciated you've had your hands full entirely, and hope that's alleviating, or soon :)