Link Control: selecting open in new tab option closes out the entire modal too quickly

[annezazu]

In testing some of the writing improvements for 6.4, I noticed that the open in a new tab control in the link preview closes out very quickly #53566 and doesn't seem to persist (edit: the value is persisted):

link.control.closing.out.too.quickly.mov

This makes for a jarring and somewhat cumbersome experience for editing links, especially if you are trying to complete a few changes to a link. I'm using 6.3.1 and GB nightly. cc @getdave and @richtabor for thoughts/replication!

[richtabor]

Yea, it's unexpected that it closes the panel. I suspect the difference is that the change is committed on the preview view, but within edit view you need to press the "Save" or "Cancel" buttons to commit.

[getdave]

From what I can see from your demo it's working as expected. I couldn't see anywhere where it is not being persisted and I've tested on trunk and all seems fine. If I missed something could you provided reproduction steps? 🙏

Note that this checkbox is provided as means to quickly toggle this setting which is something that a subset of users feel very strongly about as it's a key part of their workflow. Thus why we this is intentionally placed here. Rich's comments above are also accurate.

It is on our roadmap to consider having the control remain open when toggling settings like this. However, we need to solve a11y issues around how users of assistive technology can escape the dialog when there is no explicit close button. To neglect this would be to produce an inaccessible experience for a significant portion of our user-base.

This makes for a jarring and somewhat cumbersome experience for editing links, especially if you are trying to complete a few changes to a link

Can you explain the workflow you are undertaking here? I'm genuinely curious as to whether we've overlooked something.

If you want to make a few changes to a link you'll need to enter "edit" mode which requires clicking on the pencil icon in the dialog. The purpose of the setting toggle is not making multiple changes - it's intended to allow you to quickly toggle this one particular niche setting. TBH it's a bit of an anomaly, but as I mentioned, it's a key workflow for a subset of our users.

Note also that we're proposing removing this preview step entirely which would negate this issue in future releases. Feedback on that feature also appreciated.

[annezazu]

It is on our roadmap to consider having the control remain open when toggling settings like this. However, we need to solve a11y issues around how users of assistive technology can escape the dialog when there is no explicit close button. To neglect this would be to produce an inaccessible experience for a significant portion of our user-base.
Can you explain the workflow you are undertaking here? I'm genuinely curious as to whether we've overlooked something.

Thanks for following up and for the added context. The workflow is simple: I am adding a link and setting it to open in a new tab. In doing so, the modal closes out the second I click the checkbox, making it unclear to me if it even worked properly. Compare it to the experience of using the advanced settings where it stays open:

add.link.mov

It felt like a bug at least to me. I do dig the newer experience you're exploring here more: #50998

[getdave]

The workflow is simple: I am adding a link and setting it to open in a new tab.

Thanks. It was the "not persisting" that threw me a little because it is in fact persisting it's just (and I think this is the nub of the Issue) the fact isn't clear enough to you (as a user).

I get you. It's not ideal. @richtabor and I are aware of the suboptimal experience and working on it. However, do you still feel this qualifies as a "Bug"?

I'm open to whatever folks feel is right. Appreciate your time here to report this and provide feedback.

[annezazu]

It feels like a bug to me when the Advanced section otherwise stays open but it's likely closer to an enhancement. I'll update the labeling and we can iterate going forward :)

[annezazu]

At this point, it seems unlikely to be iterated on for beta 1 so am going to move to punted to 6.5 as well.

[annezazu]

After a review by core editor triage leads and core editor tech leads, this has been removed from the board for 6.5 consideration.

[annezazu]

Actually, I think this is fixed now that this has been merged: #57726 Closing out as I can't replicate.

[getdave]

It's been resolved by #58744

[annezazu]

Testing GB 17.8 nightly and WP 6.5-alpha-57555 on WP Playground, I'm now seeing this behavior return:

opening.and.closing.mov

I'll keep an eye on it next week to ensure it's resolved or will reopen otherwise.

[getdave]

Checking the code on Gutenberg trunk that will go into today's 17.7.0 RC release (final release going into WP 6.5) the code that would render that checkbox is no longer there.

gutenberg/packages/block-editor/src/components/link-control/index.js

Lines 424 to 434 in 194d208

	<LinkPreview
	key={ value?.url } // force remount when URL changes to avoid race conditions for rich previews
	value={ value }
	onEditClick={ () => setIsEditingLink( true ) }
	hasRichPreviews={ hasRichPreviews }
	hasUnlinkControl={ shownUnlinkControl }
	onRemove={ () => {
	onRemove();
	setIsEditingLink( true );
	} }
	/>

That's expected after #58744.

The updated packages (including @wordpress/block-editor which is where the code resides) will be synced to Core today with 17.7.0 RC. Once done then we'll want to check if this behaviour persists during the Beta/RC period.

I'll make a note to circle back.

[annezazu]

Couldn't replicate with 6.5 beta 1! Keeping closed. Thank you for your attention to detail, Dave ❤️

small.replicate.mov