Neos-ui: ContentCollection fails if it is tbody

[jonnitto]

I've created a repo with this issue to reproduce this bug: https://github.com/jonnitto/Neos.Issues

Description

If a Neos.Neos:ContentCollection has a special tagName like tbody it is only possible to create one content element. After the first one is created, it is only possible to add a new after a reload or via the structure tree

Steps to Reproduce

1. Create a content collection

<table>
    <thead>
        <tr>
            <th>Head 1</th>
            <th>Head 2</th>
        </tr>
    </thead>
    <Neos.Neos:ContentCollection tagName='tbody' nodePath='main' />
</table>

1. Create a content element

<tr>
    <td>Text 1</td>
    <td>Tetxt 2</td>
</tr>

Expected behavior

I can add multiple content element via the inline toolbar.

Actual behavior

Affected Versions

Neos: 4.2.8

UI: 3.1

[suffle]

I can confirm this problem, not only on a ContentCollection with special tagName. I get an error from a manifest.json
!!! Content Element with context path <PATH> not found in returned HTML from server (which you see below) - Reloading the full page!

where PATH is the nodePath to my newly added element. I can add new elements through the content tree though. Same UI-Version and Neos Version.

[kdambekalns]

Ok, I have a reproducer for this bevahior. Unzip the archive in a 4.2 Neos.Demo site and follow the video (you can insert any element in the "second step"):

• Testcase-2356-Neos.Demo.zip
• https://vimeo.com/324948754

The reason is non-optimal handling of the error mentioned by @suffle. The cause of course is "something in userland code", as can be seen by the fact that this case is handled.

But the (content) reload that follows does not fix it, only a reload of the full backend "fixes" the inline toolbar. Since hiding of elements does still work, I assume it's some state in the nodeCreationWorkflow (see addNode.js) that is not reset.

Sadly when I looked at the state changes in React with @kitsunet we could not spot the "missing link".

[kdambekalns]

More on the "some state" part from @kitsunet:

[interesting is] the apparent existence of some hidden state (or at least some change I couldn't figure out from the redux tools) that leads to the create new modal to be closed immediately after opening (my guess is some reset is missing when the create new went wrong)

Indeed, looking at the redux tools the modal is opened and immediately closed, everything handled correctly. As you see, apart from the Content Element […] not found, there are are no JS errors logged at all.

[kdambekalns]

More on "something in userland code": The ContentElementWrapping "invents a Fusion path", but there is nothing to be rendered there.

[kdambekalns]

Maybe I misunderstood, but my hope of this being fixed by #2395 was moot. With the latest 2.x of the UI package(s) this is still broken.

[markusguenther]

This issue has in the raw mode an additional problem. The create dialog will be not opened but the content will be added. Is a bit weird.

[kitsunet]

If you check the redux tools it looked like the respective actions were recorded correctly so they arrived in the host frame but immediately after the open action a close action was reported. So that is the issue. I couldn't find a state responsible for this though. At the moment I _think_ the "if only one possible nodetype, choose that and close" behaviour is responsible and something in the node infos is wrong when this happens. (So because node infos are screwed up somehow due to a wrong update, it decides no possible nodetypes to insert, and closes immediately without doing anything).

[dimaip]

@kitsunet try to comment out the logic for sending clicks to host document and see if it helps.

[bwaidelich]

Hey there,
this bug is critical (since it's not only about tbody etc) and we had to downgrade neos/neos-ui to version 1.4 on a major client project (you know who I'm talking about).
Unfortunately I'm still not into the whole React/Redux universe but is there anything I can help to ease/speed up the process?

[bwaidelich]

_HALP_ anyone?

[jonnitto]

How we can get here a solution? Can I help somehow?

[dimaip]

@kitsunet do you still plan looking into it or should $someone take over?

[kitsunet]

Hey all, I definitely lost track of this :(
I would be happy someone takes over :) Please

[markusguenther]

I promised @jonnitto after some beers at the social event that I will try to find a solution within this week ;)

So I give it a try but don't promise anything ;)

[dimaip]

Haha the exact reason why I don't drink at Neos events :D

[markusguenther]

@dimaip As the team tiga is complaining once a week in the meeting about this issue it was still on the list ;)

[markusguenther]

Ok short wrap up.

// We need to create the new DOM nodes from within the iframe document,
// because many frameworkds (e.g. CKE, React) use the following checks
// `obj instanceof obj.ownerDocument.defaultView.Node`
// which would fail if this node was created in Host
const tempNodeInGuest = getGuestFrameDocument().createElement('div');
tempNodeInGuest.innerHTML = renderedContent;
const contentElement = tempNodeInGuest
     .querySelector(`[data-__neos-node-contextpath="${contextPath}"]`);

The wrapping element div leads to the problem that when you have a table row for instance, that the querySelector is always returning null. We need a wrapper element that works here. As we don't have the real parent, we now just use the parent tag and search inside the element.

Please give it a try and feedback.