See https://github.com/WordPress/gutenberg/blob/master/docs/contributors/coding-guidelines.md#css

Addresses #17846 (comment)

Previously it wasn’t possible to customise the render of the search suggestions. By providing an optional render prop we now have full control over this if required.

…s render

Previously we relied on our own render of suggestions but this wasn’t hooked up to all the accessibility enhancements afforded by URLInput. By utilising the render prop exposed by URLInput to customise the rendering of suggestions, we can have the best of both worlds.

This is required to display the type of entitity in the search results for LinkControl

Previously when using the `renderSuggestions` render prop the user had to know how to put together the correct props on the correct elements in their custom render. By passing the default props for the listing element and the item element we can relieve the user of this burden by allowing them to spread the props onto the appropriate elements in their render without having to know how they are created.

Previously when a URL was entered it was deemed that no suggestions should or could be found and so the process of fetching suggestions was short circuited. Add additional prop to optionally allow developers to have URL-like values handled as suggestions.

…tcher

If the current value of the input is a URL then we conditionally pass a different handler for search results to the URLInput component. For URL based values we immediately return a “suggestion” object with values matching those entered by the user. Non URL based values are handled as previously.

Remove ambiguity by calling the search handler directly rather than proxying through another function and having to apply it immediately.

The LinkControl will be mostly where another element triggers the UI to appear. As a result we don’t want to force a toggle element on the developer. Rather we will expose an API to allow the consuming component to toggle the visibility of the LinkControl

This state is now expected to be handled by the consuming component chosing whether or not to render the component. It has no concept of open or closed.

Basically this test has revealed that due to the way we’re detecting and handling URL-like values the wrong data fetcher function gets passed to the URLInput component for the first input `change` event.

For example if you paste `https://make.wordpress.com` directly into the input then it is determined to be a URL but because the current fetcher function for the current render is still the handler that deals with entity searches the correct results are not displayed. Adding another character to trigger a re-render will cause the UI to update to the expected state, but this is a major bug.

Previously we relied on parent component state to choose which search handler to use for the current input term. However, the state was always 1 tick behind so the previous search handler got used. Updating this to use the real time value of the input passed onChange ensures we select the correct search fetcher when the component re-renders.

Spinner was technically always rendered but it wasn’t visible due to CSS styling. Fix and also cover with tests.

Addresses #17557 (comment)

Attempts to remove unwanted deps on other components. We now utilise Popover directly and suffer no consequences as we are not making use of any bespoke features provided by URLPopover.

Addresses #17846 (comment)

Fixes broken shadows in Safari which didn’t recognise transparent as a value to transition to in a gradient.

Addresses designer feedback #17557 (comment)

Addresses #17846 (comment)

Addresses #17846 (comment)

Addresses #17846 (comment)

We cannot assume the suggestion `id` will be unique. This is because at the moment the search results are `Post`s. However in the future we may also need to include `Category` terms and the term IDs could easily clash with the Post IDs as they are in different DB tables.

Using the `type` to differentiate the key.

Addresses #17846 (comment)

Addresses #17846 (comment)

Addresses #17846 (comment)

Previously only true `http` URLs were formatted with the correct type and the instructional text. Fixes so that all types of manual URL entry are correctly shown as such in the search results.

Adds test to cover mailto variant of this.

…variants

This now includes tel, mailto and internal links.

…alues that are potentially URLS

Instead of this, let's propagate the onKeyDown and onKeyPress events to the parent component

Previously if you passed in a current link the component would still render with a search box as thought nothing was selected.

Updates so that if `currentLink` is provided the UI reflects that by showing the “selected” item and no search input.

…overage

Note: this uncovered a bug whereby keyboard handling of “selecting” the link you want to use is broken. This needs to be fixed.

If the full object is not provided then consuming components have no way of accessing the details of the selected suggestion thereby rendering it useless.

…urrent link

Builds on previous commit.

Previously `buildSuggestionItemProps` was including a key. However the implementation of `LinkControl` changed so that this was not required. However we forgot to reinstate on `URLInput`. This update ensures a key prop is set on the default output.

Note that disabling of the autofocus linting was already in place:

https://github.com/WordPress/gutenberg/blob/04e142e9cbd06a45c4ea297ec573d389955c13be/packages/block-editor/src/components/url-input/index.js#L239

Addresses #17846 (comment)

Addresses #17846 (comment)

… it't needed