"Open in new tab" property is not always saved when "Save draft" is used

[tofumatt]

Describe the bug
The "Open in a new tab" setting is not persisted if "Save draft" is used after it is set and the inline editing screen is not closed.

This happens in Gutenberg in the latest version of WordPress and with Gutenberg on master.

To reproduce
Steps to reproduce the behavior:

1. Create a new post or load an existing post with several paragraph blocks that have text.
2. Create a link for some of the text to a URL.
3. Save the post as a draft.
4. Select a link you made and click the "edit"/pencil button (sometimes this is buggy for me, at least in Firefox, but keep trying until it appears).
5. Change the setting of "Open in new tab" to "on".
6. Click "Save Draft" and then blur the link you have open by clicking on the title or another block, hiding the link selection.
7. Wait until the draft is saved.
8. Check the link. It will not have changed setting (it's still set not to "open in new tab").

Expected behavior
The setting is changed and saved immediately, and saving is not blocked by the "Save draft" button.

Screenshots

Desktop (please complete the following information):

• OS: MacOS (10.15)
• Browser Firefox 72.0b11 (64-bit), Chrome 79.0.3945.88

[bartczyz]

There is definitely something fishy going on with URLPopover component.

In your case Save to draft didn't kick in, cause you never submitted the form with the URL. IMO the Link Settings should be only visible and accessible with LinkViewer and not LinkEditor.

What is also weird is that when you already have a link and you want to click the Edit icon the popover disappears and the caret returns to the beginning of the paragraph and you need to click the link again in order to open the URLPopover.

I also think that if you're in LinkEditor mode then when you click outside the container and the popover disappears it should go back to LinkViewer.

[m]

How’s this one going?

[aduth]

Possible duplicate of #17334.

At least when changing "Open in New Tab" after pressing the Edit (pencil) icon, it appears (based on inline code comments) to have been intentional that changes which occur while in that editing mode would only persist once clicking the "Apply" button next to the input field, or pressing Enter while in the URL input. This can make sense for edits to the URL itself, which should only take effect after a user has finished their changes and explicitly decides to commit them. However, demonstrated by this issue, it's not a very clear interaction for the "Open in New Tab" toggle, which I think would be reasonable to expect should always take effect immediately.

In your screencast, it might appear as though you've expanded and changed the value of "Open in New Tab" without first pressing Edit (pencil), but because you had already pressed the button once earlier (and the dialog disappeared), this might actually have been another issue which has since been resolved in Gutenberg 7.2.0 (#19394, fixed by #19440) where the editing mode has taken effect and carried over from the first time the dialog was shown. I'm sure this would have contributed to the confusion, because even if the user does understand that URL edits must be committed, this bug might have led them to think that they're not editing the link, and thus the toggle should be applied immediately.

The screencast in #17334 would seem to show that the toggle value is reset even when not first having clicked the Edit (pencil) icon. I'm not yet clear if this is an issue specific to the Make/Core blog, since I've been unable to reproduce locally. It could be a case that the site is running an older version of the plugin, or that there is custom server-side filtering which is removing the link target. Otherwise, my first thought was that this could be a race condition between the link dialog closing (where the changes are applied at the closing of the modal) and the "Save Draft" click accounting for those changes. However, based on the implementation and assuming the user is not in this editing mode, toggling the "Open in New Tab" should take effect immediately upon click, and not when the dialog is closed.

Worth noting: There are some work-in-progress iterations being made to this link editing experience at #19462, which may resolve some or all of the issue. At least, it removes the uncertainty around whether the toggle should apply immediately because the "Open in New Tab" toggle is no longer shown when the user is editing the link (instead, it's still and only shown when first clicking the link to view it).

As action items, I might propose:

• Continue link iterations at Try the link control in the link format #19462, which would resolve this in a roundabout way, ensuring that "Open in New Tab" always takes effect immediately
• Because Try the link control in the link format #19462 may require more time before landing, we could decide to address this in the interim by changing "Open in New Tab" to apply immediately, even if the user is currently editing the link
• Follow-up at Bug: Open link in new tab removed when saving draft #17334 in case it can be verified that link toggling is reset even when not editing the link

In the meantime, the user-facing workaround is:

• When clicking the Edit (pencil) button, you must press the "Apply" button to the right of the input field for any changes to take effect.

[aduth]

This is resolved by #19462, which removes the ambiguity of "Open in New Tab". Toggling the option should always take effect immediately. Noting also this is part of the general effort of a revised link editing UX, described at #19270.

[aduth]

#19462 had regressed usability for common keyboard workflows in link editing, so the "Open in New Tab" toggle has been reintroduced to link editing as part of #20052. There is discussion in #20007 related to this balance of keyboard usability and settings availability.

In mind of the potential for confusion that had existed previously, the following accommodations were made:

• The toggle will always take effect immediately, per design guidelines for toggles.
• The visual states of "Previewing" and "Editing" a link are more visually distinct.