HtmlArea breaks after drag n drop


#1

Enonic version: 6.15.5
OS: Mac Mojave

HtmlAreas inside an Option-set inside an Item-set breaks when dragging and dropping the item block it is in. It becomes untargetable and the text and controls disappears.

The HtmlAreas work after dragging and dropping when only in a item-set, but nesting them deeper into an option-set seems to introduce a similar bug as HtmlArea not editable after drag and drop

Here is a quick xml content type to test:

<content-type>
    <display-name>Test</display-name>
    <super-type>base:structured</super-type>
    <form>
        <item-set name="blocks">
            <label>Blokk</label>
            <occurrences minimum="0" maximum="0" />
            <items>
                <option-set name="type">
                    <label>Type</label>
                    <expanded>false</expanded>
                    <occurrences minimum="1" maximum="1"/>
                    <options minimum="1" maximum="1">
                        <option name="text">
                            <label>Tekstblokk</label>
                            <default>true</default>
                            <items>
                                <input name="textblock" type="HtmlArea">
                                    <label>Tekst</label>
                                    <occurrences minimum="1" maximum="1"/>
                                </input>
                            </items>
                        </option>
                        <option name="fact">
                            <label>Faktaboks</label>
                            <items>
                                <input name="facttext" type="HtmlArea">
                                    <label>Tekst</label>
                                    <occurrences minimum="1" maximum="1"/>
                                </input>
                            </items>
                        </option>
                    </options>
                </option-set>
            </items>
        </item-set>
    </form>
</content-type>

#2

Thank for you reporting this. We fixed this bug in the past (6.15.2, I think) but it seems to have reappered again. We’ll fix it in the 7.0 release.