Hello team! First off, thank you for your efforts!

My team will adapt Froala for our project, we are in the process of rewriting our code to use it.
I have a bug where the editor freezes (content becomes uneditable) in case a model update happens before the initialize event.

Repro: https://stackblitz.com/edit/stackblitz-starters-k35b4oxe

We have wrapper component which has a model input and displays that input in Froala:

<div
    class="editor-root"
    [froalaEditor]="richTextEditorStore.froalaOptions"
    [froalaModel]="value()"
    (froalaModelChange)="richTextChanged($event)"
></div>

export class RichTextEditorComponent implements OnInit {
    richTextEditorStore = inject(RichTextEditorStore);

    value = model('');

Our consumer component uses this to bind to a property of a complex object. The complex object is loaded from the back end.

 <rich-text-editor
    [(value)]="obj.message"
    [readOnly]="isReadOnly"
></rich-text-editor>

  obj = {} as { message: string | undefined };
  // later
  get().subscribe(obj => {
     this.obj = obj; // obj contains message
  })

We log the initialize event and the model updates as well. I noticed that the initialize fires after the model update, and the editor gets stuck. Not sure if that has relevance:

// froala options...
    events: {},
  };

  registerCommands() {
    const self = this;
    this.froalaOptions.events['initialized'] = function () {
      self.captureEditorInstance(this);
      console.log('initialized');
    };
  }

  captureEditorInstance(editor: FroalaEditor) {
    this.editorInstance.set(editor);
  }

The instance capturing part I included in here and in the repro as well in case it might be relevant, we use that for implementing the readonly functionality.

It seems that the fr-wrapper div does not get created in this case, and the content (<p>text</p> and <p>e</p> in the examples) gets placed and interpreted as literal HTML:
Good:

Bad:

Two important notes:

1. Wrapping the editor root in an @if(value()) fixes the issue, but it seems like an unnecessary workaround. I don't even understand why this would fix the issue.
2. The same behavior presents itself even if the initial value of obj.message is not undefined but some truthy value, like <p>sample text</p>. This makes the workaround in point 1 even stranger.