WYSIWYG editor field on builder disappears sometimes?

[TakumiHendricksDev]

I’m not exactly sure of the best way to replicate this in StackBlitz. I haven’t been able to make it disappear there, but in production, very rarely, the WYSIWYG field on the builder form will sometimes disappear. When inspecting the HTML, it appears that the input div has a display: none style applied.

<div class="vfb-preview-element-container vfb-preview-element-container-md col-span-12 form-text-type" data-path="Hopes" tabindex="-1" aria-label="Hopes" aria-describedby="Hopes__aria-description" style="display: none;"><!-- There's more content here but the rest of it doesn't matter i believe--></div>

I've also send this message to the discord help channel, but it seems this is the preferred place for issues.

[TakumiHendricksDev]

I've also attempted to use AI to potentially debug the issue, so the jotted notes here might be wrong and you should take this with a grain of salt.

Root Cause: Vueform core's v-show="visible" on ElementLayout

The style="display: none;" is applied by vueform core, not by your system and not by trix. Here's the chain:

1. The mechanism

File: node_modules/@vueform/vueform/themes/blank/templates/ElementLayout.vue:2

The vfb-preview-element-container class is added to this same container div by the builder (via its class merge system). So the v-show="visible" directive is what controls the display: none.

2. The visible computed property

File: node_modules/@vueform/vueform/dist/core.mjs:22350
var visible = computed(() => {
return available.value && !hidden.value && active.value;
});

Since the "Hopes" field has no conditions, available should always be true. That leaves two suspects:

• hidden (default false, only changed via .hide() / .show() programmatically)
• active (default true, but set to false by the steps/pages system for elements not on the active page)

3. Why it's intermittent and WYSIWYG-specific

The builder uses steps (pages). During form loading, the steps system assigns elements to their pages and sets active accordingly. The trix-editor is a web component with async initialization (setTimeout(fn, 0) for
customElements.define, requestAnimationFrame for toolbar/editor setup).

This creates a race condition:

1. Vue renders the form elements

2. The steps system evaluates which step each element belongs to

3. The trix-editor's web component starts initializing asynchronously

4. During trix's async init, it modifies the DOM (creates toolbar, hidden input, dispatches events)

5. These DOM mutations can trigger Vue's reactivity/MutationObserver

6. This can cause the steps system to momentarily lose track of the element, setting active = false

7. v-show="visible" applies display: none

8. The state doesn't recover because the trix editor is now in a broken init state

9. The trix console warning is a separate (but related) symptom

The warning "This browser does not support the [disabled] attribute for trix-editor elements" comes from trix's fallback class (ro) at the bottom of the trix source. The EditorWrapper passes disabled as an attribute to
via v-bind="options" (core.mjs:21988-21994). When the fallback class's disabled getter is accessed, it logs this warning. This doesn't directly cause the display: none but confirms the trix-editor isn't fully
initializing in the builder context.

5. Verdict: Vueform bug (interaction between vueform builder's steps system and the trix-editor web component)

It's a vueform issue where:

• The ElementLayout uses v-show="visible" which depends on active
• The builder's step system + trix async initialization creates a race condition
• The builder should be overriding visible in builder mode (the builder's ElementLayout setup at plugin.mjs:2011-2895 does NOT override visible)

Debugging suggestion

To confirm, open browser devtools when the bug reproduces, select the hidden element, and in the Vue devtools check:

• el$.visible — should be false
• el$.available — should be true (no conditions)
• el$.hidden — check if true
• el$.active — this is likely false (the culprit)

[adamberecz]

There hasn't been any issues around this reported by other so it is either something environmental or happens in a weird / specific edge case. If you manage to put together a reproducible example I'm happy to have a look at it.