Save field value even if suggestion not selected

Setting this issue priority to "Major," since I consider this to be a significant user experience problem. Will review this soon.

MR !28 adds support for maintaining fragments and query strings (the issue that @marcoscano noted in the LinkIt for Fields issue).

MR !28 adds support for maintaining fragments and query strings (the issue that @marcoscano noted in the LinkIt for Fields issue).

I'm unable to reproduce an issue specific to query parameters or anchor links that seems to necessitate the more substantial change proposed in MR !28.

The less substantial change proposed in #2 seems to resolve all scenarios that I have tested. If there is a scenario that requires the more involved change proposed in the MR, can someone provide steps to reproduce?

Here are the steps that I used to test #2 that demonstrate that the patch resolves the original problem:

Scenario 1: Basic URL; Patch #2 passes

1) Configure a node link field to use Linkit widget
2) Create a node and set the link field to an internal route on the link field. After save, the link to the internal route will display correctly.
3) Open the node edit form. Type into the URL field "https://google.com"
4) Do not click on the dropdown suggestions. Instead click "Save" to save the node directly.
5) Check that field value seems to have changed first in the node view and then go back to node edit to see the old value back.
6) Go back to node edit and verify the value "https://google.com#test" is preserved.

Scenario 2: URL with query parameter; Patch #2 passes

1) Configure a node link field to use Linkit widget
2) Create a node and set the link field to an internal route on the link field. After save, the link to the internal route will display correctly.
3) Open the node edit form. Type into the URL field "https://google.com?test=1"
4) Do not click on the dropdown suggestions. Instead click "Save" to save the node directly.
5) Check that field value seems to have changed first in the node view and then go back to node edit to see the old value back.
6) Go back to node edit and verify the value "https://google.com" is preserved.

Scenario 3: URL with anchor link: Patch #2 passes

1) Configure a node link field to use Linkit widget
2) Create a node and set the link field to an internal route on the link field. After save, the link to the internal route will display correctly.
3) Open the node edit form. Type into the URL field "https://google.com#test"
4) Do not click on the dropdown suggestions. Instead click "Save" to save the node directly.
5) Check that field value seems to have changed first in the node view and then go back to node edit to see the old value back.
6) Go back to node edit and verify the value "https://google.com#test" is preserved.

Scenario 4: URLs with differing queries: Patch #2 passes

This scenario specifically tries to test the comment in MR 28:

+ // If any of the these properties differ between the two URLs, the
+ // hidden inputs storing options field data will be cleared.
+ // Essentially, we leave out any of the props that contain URL
+ // fragment (#) or query string (?). These include hash, href,
+ // search, and others.

1) Configure a node link field to use Linkit widget
2) Create a node and set the link field to an internal route on the link field. Append #foo to the internal route in the edit form. After save, the link to the internal route will display correctly, with the #foo anchor
3) Open the node edit form. Type into the URL field "https://google.com#test"
4) Do not click on the dropdown suggestions. Instead click "Save" to save the node directly.
5) Check that field value seems to have changed first in the node view.
6) Go back to node edit and verify the value "https://google.com#test" is preserved.

Thank you for the review and thorough testing scenarios @mark_fullmer! 🙏🏻🙏🏻

I think the bug @marcoscano referred to was with the clearing of match metadata stored in the link field's "options" array. I didn't actually test his patch until now, and found out it breaks a little worse than I thought. I expected:

Match metadata gets saved if autocomplete dropdown is clicked, but cleared if the user "keyups" in the textfield.

But it actually works like:* **

Hidden form inputs always get cleared, even when the autocomplete dropdown is used to click an entity matcher and the user has no direct interaction with the textbox.

*Tested in Firefox on linux
**EDIT: I realized this is partially due to the placement of the listener. But even when I attached it to $uri instead of $autocomplete, it still had some bugs, where it would clear the previous item's metadata as soon as you edit a different item in the multivalue link field.

Specifically, the options data we lose with the first patch are:

• data-entity-type
• data-entity-uuid
• data-entity-substitution

The approach in MR 28 attempts to be less aggressive in clearing the match metadata. Specifically when any portion of the link changes, besides query string and fragment.

Thanks for clarifying, hawkeye.twolf! I understand how the patch in #2 is too aggressive. (The way I'd put it is: the hidden form inputs should not be cleared until a user either explicitly accepts the autocomplete suggestion or saves the form. Testing the MR with this in mind, it makes good sense to me.

Merged into the 6.0.x and 6.1.x branches.

Great :D I see new releases already cut—thanks so much @mark_fullmer!