Keep Link UI open upon initial link creation when used in RichText #57726
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
getdave
added
the
[Feature] Link Editing
getdave
commented
Jan 10, 2024
|
Here is an example of what occurs if we don't force the re-computation of the popover anchor in Screen.Capture.on.2024-01-10.at.15-17-11.mp4 |
getdave
force-pushed
the
try/keep-link-ui-open-on-initial-link-creation
branch
from
d54866b to
5959090
Compare
|
Size Change: +364 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
getdave
changed the title
getdave
added
[Package] Rich text
getdave
commented
Jan 10, 2024
scruffian
previously approved these changes
Jan 11, 2024
|
Bugs
|
jeryj
reviewed
Jan 11, 2024
I say we do a follow-up soon to tidy up this preview in general (#53654). Perhaps something like this: 
|
richtabor
previously approved these changes
Jan 11, 2024
|
@jeryj @richtabor yup I agree with refined previews. I'll merge this after I fix these bugs |
This was referenced Jan 11, 2024
|
This will also close #53656 |
|
I feel like this one will be well-received in general and I personally like it a lot, but it might also be seen as adding an extra click. @getdave if I type space or return after adding the link while the modal is open, does that action closes the modal and return the focus to the text cursor? |
getdave
commented
Jan 12, 2024
…pdate hook" This reverts commit cbcbf41. # Conflicts: # packages/rich-text/README.md # packages/rich-text/src/private-apis.js
draganescu
force-pushed
the
try/keep-link-ui-open-on-initial-link-creation
branch
from
b20085c to
011fe3b
Compare
draganescu
approved these changes
Jan 23, 2024
There was a problem hiding this comment.
I think this PR solves a huge UX issue that was just too easy to overcome to be pressing but extremely annoying (closing the link ui immediately after creating the link).
I think Dave addressed all the original issues with the udpates to rich text and alos I don't think the focus trap issue (pre-existing) is blocking this PR.
getdave
commented
Jan 23, 2024
|
Thanks for your review @draganescu 👍 Noting that in order to merge this PR we'll need to address the e2e test failures and ensure they aren't failing due to valid regressions. |
…oss editing links
|
Flaky tests detected in b94bdec. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7628155823
|
getdave
commented
Jan 23, 2024
|
|
||
| // Deselect the link text by moving the caret to the end of the line | ||
| // and the link popover should not be displayed. | ||
| await pageUtils.pressKeys( 'End' ); | ||
| await expect( linkPopover ).toBeHidden(); |
There was a problem hiding this comment.
Should we invert this instead? toBeVisible()?
There was a problem hiding this comment.
You'd need to do a little bit more, since the focus is in a different spot. I modified it to match the spirit of what the test was already testing. fb8f5a9
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
When a link is initially created within Rich Text, instead of automatically hiding the Link UI, this PR will keep it open to allow further editing of the newly created link (e.g. toggling link settings...etc).
Moreover, when toggling the
Opens in new tabcheckbox on the "Preview" state of the Link UI, the UI will no longer automatically close.Closes #53656
Why?
This allows users to create a link and then immediately edit it's properties without having to go through the process of re-activating the link they just created. This solves a number of issues and is better UX.
How?
This PR has a number of changes which should be carefully assessed:
useAnchornow exposes aupdatemethod on the returnedanchorobject. This is to allow consumers to force the anchor to be updated which may be required under very specific circumstances (such as in this PR).RichTextValuewhen the Link UI is submitted, which means the link format remains active, which means that the Link UI continues to be displayed.keyprop on theLinkControl. This was causing focus loss on initial link creation because the focus target was removed from the DOM when the component was remounted. This is because thekeyprop was computed because on theanchorreturned fromuseAnchorwhich (due to the next UX requirements) now changes whilst theLInkControlcomponent is rendered. I believe this forcable remount has not be necessary since we undertook improvements to the internals ofLinkControlbut I'm pinging @kevin940726 for a confidence check.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
Screen.Capture.on.2024-01-10.at.21-20-59.mp4