-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Editor: Handle LinkControl submission via form handler #19651
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -52,6 +52,9 @@ async function updateActiveNavigationLink( { url, label } ) { | |
await page.type( 'input[placeholder="Search or type url"]', url ); | ||
// Wait for the autocomplete suggestion item to appear. | ||
await page.waitForXPath( `//span[@class="block-editor-link-control__search-item-title"]/mark[text()="${ url }"]` ); | ||
// Navigate to the first suggestion. | ||
await page.keyboard.press( 'ArrowDown' ); | ||
Comment on lines
+55
to
+56
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This demonstrates another issue which existed previously, where even if the user hadn't yet selected a suggestion, pressing Enter while suggestions are merely present would select one of them, rather than the use the user's input verbatim. This is related to the behavior described in #19490 (comment) regarding how using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree. I think we need to decide on the UX here before we proceed. Is it:
Personally, if we go for #2 then we need to know our validation logic is absolutely sound else we're restricting what can be added as a link. We'd also need a means to display a validation error warning within the UI to the user if the entered text is not considered valid input. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For me, I don't think we should use a suggestion unless it is "selected", assuming that we already have this mechanism for suggestion selection. What I don't feel as strongly about is whether we choose to have a suggestion be selected by default. For example, we could have the first suggestion be selected by default, which might be a search result or otherwise the raw URL if no other search results exist (so, still optimizing for Enter inputting raw URL without any other interaction). If we choose not to have a suggestion be selected by default, then I think we should be comfortable that if there is no selected suggestion, and I've entered something like "Contact Us" which yields a result, pressing Enter should either treat it like a raw URL (even if it's not technically valid) or do nothing until the user makes a selection or cancels the prompt. I can see this being a case for having a default selection, since none of this sounds like a very good user experience. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm inclined to consider this non-blocking. The changes in this pull request aren't intending to influence this behavior, outside the fact it removes incidentally |
||
// Select the suggestion. | ||
await page.keyboard.press( 'Enter' ); | ||
} | ||
|
||
|
@@ -138,12 +141,5 @@ describe( 'Navigation', () => { | |
|
||
// Expect a Navigation Block with two Navigation Links in the snapshot. | ||
expect( await getEditedPostContent() ).toMatchSnapshot(); | ||
|
||
// TODO - this is needed currently because when adding a link using the suggestion list, | ||
// a submit button is used. The form that the submit button is in is unmounted when submission | ||
// occurs, resulting in a warning 'Form submission canceled because the form is not connected' | ||
// in Chrome. | ||
// Ideally, the suggestions wouldn't be implemented using submit buttons. | ||
expect( console ).toHaveWarned(); | ||
} ); | ||
} ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to decide what should be used for
title
here, or at least revise how we're currently treating an empty/unsettitle
in the top-levelLinkControl
. Right now I see this issue when entering a raw URL, where the "external link" is empty:master
fix/link-control-submission
I think
master
is problematic in how it will apply the raw URL as atitle=
attribute of the rendered navigation/button links, but that could be argued to be a separate issue.It ties in a bit with #19387 in trying to get some meaningful title from a raw URL, but I think we'd want a sensible fallback for when that can't be retrieved.
Personally, I think it would be expected to omit the
title
(or have atitle: null
) for this fallback of manual/raw URLs. That requires updating the implementation ofLinkControl
to handle this better for its rendering ofExternalLink
.As I write this, I realize this might have been (in part) what @youknowriad was intending in #19462 with the use of
displayURL
here: https://github.com/WordPress/gutenberg/pull/19462/files#diff-106913d5079b57c6032c0775292d8d9dL205There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also noting that this is something where having a well-defined
value
shape is important.title: null
like I mentioned previously may be a semantically-reasonable way to represent an unknown title, but it requires that this is well-understood in how the value is applied. Currently, the blocks do seem to anticipate that this could be empty, but that "empty" would mean explicitlyundefined
:gutenberg/packages/block-library/src/button/edit.js
Line 104 in 669549a
In the above code, a
title
ofnull
would not cause the fallback empty string to be used, and may break the block if it assumes from that point forward that thetitle
is guaranteed to be a string.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See: #19739