Description

In #17972 (comment) we learnt that if any inline link (within paragraph text) has an empty href then the Link UI can end up in an unexpected "preview" state. This UI state provides no feedback to the user as to the cause of the error.

This PR resolves that by switching to rendering an "error" state in the link preview if the value's url prop is empty.

This does not attempt to resolve the situation where you create an empty link using the Link UI. That's handled in a companion PR.

Fixes #17972 (comment)

Why does this happen?

Back when it was created a forceIsEditingLink prop was addd to the <LinkControl> in order to force it in and out of "editing" mode.

This was then utilised in the "inline link" part of the format library to allow various user UI actions (example) to trigger the Link UI.

However, this allows for an edge case - if forceIsEditingLink is set to false and the value.url is falsey then:

• the Link UI's "Preview" will be force-shown.
• the "Preview" will be empty due to the absence of a URL in the value.url property.

Other options considered

I did consider updating the <LinkControl> to reverse the effect of forceIsEditingLink if:

1. The value of forceIsEditingLink is false, AND...
2. The value of value.url is empty.

If I had done that then even if forceIsEditingLink was false then the Link UI would not render the preview or the editing mode because of the absence of a valid value.url.

I decided not to pursue this as the prop is very explicitly forcing a state on the LinkControl and therefore I wanted to avoid "magic" within the component subverting that "instruction".

How has this been tested?

We have a new unit test coverage for this scenario.

You can also manually test:

1. Add a paragraph.
2. Create a link (to anything).
3. Switch to "Code" view.
4. Alter the link by setting the href to an empty string.
5. Switch back to Visual mode.
6. Click on the link to trigger the link UI.
7. See the new "Error" state.
8. Click edit to check it's possible to "fix" (re-instate) the link.
9. Check other editors.

Screenshots

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).