Completed as of #4311 and Draftail 0.17.0.

Have created a PR for updating the HTML->contentstate converter: #4311. Unless I’m missing something, this change doesn’t break WYSIWYG - effectively, it just performs a one-off fixup of hallo.js content to add the spacer paragraphs that Draftail expects. From that point on, it’s functionally the same as content entered through Draftail, and the spacing will match what appears on the front-end.

Further trying this, there seems to be quite a few parts of Draft.js where “no content blocks” will throw an error. At least the parts that Draftail uses do. I’m not sure whether this can be considered a bug or a feature, but for now let’s assume there has to be at least one block for the editor to be functional.

With this in mind, I think the simplest and most future-proof solution would be to change the editor behaviour when removing block-level entities like IMAGE and EMBED so that instead of completely removing the block, it replaces it with an empty one and moves the cursor there. This is similar to how Google Docs and MS Word delete images.

Current behavior:

Proposed behavior:

This makes it impossible for fields to lose all their blocks when removing an image/embed, and doesn’t introduce workarounds to wrap images with unstyled blocks, which we would want to remove later on.

How does that sound?

To reproduce ‘Deleting an image can delete the whole field’:

• Enable hallo.js via the setting:

    WAGTAILADMIN_RICH_TEXT_EDITORS = {
        'default': {
            'WIDGET': 'wagtail.admin.rich_text.editors.hallo.HalloRichTextArea'
        }
    }
  

• Edit a rich text field; delete its contents and continue pressing backspace until the ‘P’ toolbar button becomes un-highlighted

• Insert an image; after the modal closes, do not re-focus the rich text field. Hit ‘publish’.

• Enable draftail by removing the setting above, and re-edit the page

• Click on the image and hit ‘delete’

I’d expect the html-to-contentstate converter to produce the same output for <img /> and <p><img /></p> - namely, an unstyled block consisting of a single space character with an entity definition on it. Since it apparently isn’t doing so, I think the converter code is at least partly at fault - I’ll investigate.

Hey @BertrandBordage, iIt’s great that you have feedback, especially coming from end users. I don’t think you should limit what’s listed here to what you deem critical / easy to notice though – the more the merrier, and there might be non-critical things that are really easy to fix. It’s better to make the call of whether to release or not with a fuller picture.

If anything, I’d encourage more organisations to take Wagtail 2.0rc1 (or at least https://www.draftail.org/, and the new docs!) to end users before the final release. No matter the merits of the new editor, if people didn’t feel the frustrations of Hallo before they won’t appreciate having a replacement forced on them.

For the specific issues,

• The whole field disappearing is because the editor crashes. I proposed adding a specific UI for this scenario so it would look less broken, but didn’t get around doing it. (it also shouldn’t crash to start with). I’m actually already aware of this specific issue with images because early on I put client-side error tracking with Sentry in the Draftail demo. Unfortunately the amount of traffic / usage this got isn’t really enough to realise the extent of the problem, and I didn’t manage to reproduce it myself. I’ll try harder.
• For #4295 – yep.
• The alt text field being an input – yep. If anyone wants to have a stab defining what this should look like or making a PR, go ahead.
• The “Alt text” being too big and without borders is weird. Would you have some cached stylesheets by any chance? Otherwise could you let me know which browser, version and OS?

For floating images, that’s something we can revisit later on if we want to. The problem with Hallo is that it doesn’t have a defined behavior – it just “happens to work”, sometimes, and people who use it often enough and are tech savvy enough learn to avoid problematic mouse patterns. I’m keen to hear what people think would be the right behavior. The other problem is image formats being dev-customisable: if left and right alignment works, then you also expect center alignment, and full-width, and outset left and right and both to work as well.

For moving images, it was possible in Hallo but again the behaviour wasn’t defined and it happened to work in some cases. I know of two ways to do it in Draftail:

• Cut-paste.
• Text drag and drop. Edit: This is something there has been some reported issues with, and I never use this myself so can’t really judge whether they are present in Draftail.

Unfortunately, right now in both cases you have to start and end the selection in the preceding and following blocks (even without selecting any of their text). I’m not sure if that’s a limitation of Draft.js or of my code (I think it’s probably my code). This is what it looks like:

Drag and drop “like Hallo” would be really cool. There are handlers for this in Draft.js, they just aren’t implemented.