Default value for search field - (#11420 Easy within-site linking from new content)

[jamie.richard]

The within-site linking available in the current release candidate looks like a great idea, but I'm wondering if it might make sense to pre-popular the search box area with the selected text that is highlighted.

Currently the search box (which is actually more of a filter box) is empty by default, but it seems to me that most of the time if you are linking to internal content, you will be linking to the material you are highlighting which will have a similar title.

[nacin]

This definitely came up for discussion. So much so that I thought we did this and that it worked. I'll pass this on to those who worked on it more than I did.

[nacin]

Either way, 3.2 material at this point.

[kovshenin]

Refreshed in 16276.2.diff​

[helen]

Patch seems to work for me. I think we should do this.

[greuben]

16276.3.diff​

Patch for Visual & HTML editors.

[DrewAPicture]

16276.2.diff​ works as expected for me in both editing modes ... not sure what the significance of 16276.3.diff is.

[sillybean]

16276.2.diff​ works for me. I love this. Can haz?

[helen]

I needed .3 for it to work in both modes. Reviewing now.

[helen]

In 24841:

Set the default internal search value for the link dialog to be the text that is highlighted in the editor. props greuben. fixes #16276.

[helen]

Two things being noticed here, reported by a .com VIP site as well as myself:

• Cursor shouldn't be in the search field by default when opening the modal, as it breaks previous behavior and prevents quick keyboard usage. I actually do it this way myself fairly often: opt-shift-A, paste URL, enter.
• Auto-searching can slow things way, way down. Not sure what the right route is here - don't trigger the search and just auto-populate the field? Something else?

[greuben]

Replying to helen:

Two things being noticed here, reported by a .com VIP site as well as myself:

• Cursor shouldn't be in the search field by default when opening the modal, as it breaks previous behavior and prevents quick keyboard usage. I actually do it this way myself fairly often: opt-shift-A, paste URL, enter.

The focus from the URL field is removed when the search results box is toggled. The cursor stays in the URL field if the search results box is already open.

• Auto-searching can slow things way, way down. Not sure what the right route is here - don't trigger the search and just auto-populate the field? Something else?

Maybe trigger auto-search if the search results box is visible/open.

[helen]

I like the approach in 16276.4.diff​. Tested well for me and hasn't met any objections yet, so dropping it in.

[helen]

In 25031:

Only set and run internal search for linking selected text if the panel is open. Make sure the focus is in the URL field whenever opening the linking modal to preserve previous behavior. props greuben. fixes #16276.

[bradyvercher]

I have a plugin that incorporates functionality similar to this and heard complaints about auto-searching being slow (a few seconds) when a site has a lot of content. I see a couple of issues with this:

1. HTML isn't stripped from the search term when the modal is opened in HTML mode. Try placing a link around a string with an >em< tag in it.

2. For anyone encountering slowness, the experience here is suboptimal. They can't realistically disable the auto-search without closing the search panel after selecting a result before clicking the "Add Link" button. Otherwise, the auto-search fires next time a link is added to any post since the panel state is remembered. Are we really going to ask them to do that? (I had to incorporate a setting in my plugin and don't think core wants to go that far.)

3. By following the previous step (close panel before adding the link), if a second link is inserted into a post, the search term stays the same. That's the current behavior and no big deal, but it feels weird when toggling the panel to have the previous term remain.

[helen]

Seems rife with issues - what do we want to do here? Revert? Try something else? Try again later?

[helen]

Gonna revert. Bunch of problems that don't seem have to a clear path forward when all taken together. We can try again later.

[helen]

In 25528:

Revert [25031] and [24841] - filling the internal linking search field with selected text has UX and performance issues with no resolution in sight. see #16276.

[iseulde]

Patch above addressed most of the issues above, I think. If it's slow because the site has a lot of content, then yeah, can't do much about that. But it would be slow for the front-end of the site too and if you manually search (and trigger more requests). In that case you can just hide the search functionality and no more requests will be sent.

With patch it only sends a request for the "recent" search when needed. Also re-opening the modal with the same search won't trigger another request.

I think this is probably the best we can do, so if it still has issues it's better to close. Let's decide in the 4.2 cycle.

[ryan]

How does the patch behave on mobile? IIRC from last time around, putting default values in the search field (focusing the search field by default) caused keyboard fly up when opening the link modal on touch devices.

[iseulde]

Replying to ryan:

How does the patch behave on mobile? IIRC from last time around, putting default values in the search field (focusing the search field by default) caused keyboard fly up when opening the link modal on touch devices.

I believe the URL field is also auto-focussed on mobile, so that would result in the keyboard flying open. This patch does not move the focus to the search field, but I will take a look and confirm.

[DrewAPicture]

Replying to iseulde:

Patch above addressed most of the issues above, I think. If it's slow because the site has a lot of content, then yeah, can't do much about that. But it would be slow for the front-end of the site too and if you manually search (and trigger more requests). In that case you can just hide the search functionality and no more requests will be sent.

I don't think we can simply dismiss the slow-search argument since that's one of the very specific reasons [25031] and [24841] were reverted.

With patch it only sends a request for the "recent" search when needed. Also re-opening the modal with the same search won't trigger another request.

I can't really think of a common use case where you would search the same highlighted (or typed) text more than once.

I think this is probably the best we can do, so if it still has issues it's better to close.

I agree that if a consensus on a good experience can't be met we should just close it. Moving to low priority for now.

[helen]

Replying to iseulde:

slow because the site has a lot of content

This remains a dealbreaker.

After having tried this again in practice (previously and again recently), as well as bradyvercher's hands-on observations, I think this is perhaps a wontfix after all. It sounds really cool in concept, but in practice it's not really as common to want to search for the words you've selected within your own site. If a particular site does do this all the time, then a plugin is a great fit.