1504847 - Disable search shortcut highlighting etc. for non-@ shortcuts

Status: RESOLVED FIXED

(Firefox :: Address Bar, enhancement, P1)

Description

[Drew Willcoxon :adw]

Bug 1500545 has context:

(In reply to Drew Willcoxon :adw from bug 1500545 comment #4)
> Verdi and I talked about this today.  The problem with requiring a space
> after shortcuts is that we want to recognize shortcuts as you're typing them
> -- or more accurately potential shortcuts, i.e. their prefixes.  That's
> because we want to show in the popup all the shortcuts that match what
> you're typing and nothing else.
> 
> But that behavior conflicts with shortcuts that happen to be prefixes of
> other words you might want to search for, as Bruce points out.
> 
> We decided that we shouldn't treat @ shortcuts and non-@ shortcuts the same.
> @ shortcuts turn on "search mode" -- shortcut highlighting, search
> suggestions, showing matching shortcuts in the popup, and all the other new
> behavior we've been working on.  Non-@ shortcuts/keywords should go back to
> behaving how they did before we added all that new behavior -- no
> highlighting, etc.  Users can prefix their custom keywords with @ to get
> them to behave like the built-in @ shortcuts.
> 
> Personally I think that's kinda too bad.  I'd prefer us not to distinguish
> between the two, and I think it's kind of heavy handed to treat them
> differently just so we know to show only matching shortcuts and nothing else
> as you're typing.  I also don't really like requiring a special character to
> turn on search mode.  I like how Chrome and Safari don't require that.  We
> talked about all that too and maybe we can continue to think about it.

Comment 1

[Marco Bonardo [:mak]]

I think having the @ char enable a special "command" behavior may be nice in general, it would activate only if it's the first char of the search string, and may be followed by a command. In this case the command is a search shortcut, in the future it may be bookmarks, tabs (as suggested) or maybe even more (at that point we have a way to enable special commands).
The immediate advantage is that we can attach different behaviors to it, without the risk of messing up normal searches, for example if you type @ama and we complete [zon], as soon as you confirm the completion we may add a whitespace, so it ends up as "@amazon |" where the cursor is already correctly positioned to type your search terms.
I think this has potential, and could be better than "tab to search" since you start with a deliberate decision to type "@".

Comment 2

[Mike de Boer [:mikedeboer]]

(In reply to Marco Bonardo [::mak] from comment #1)
> I think this has potential, and could be better than "tab to search" since
> you start with a deliberate decision to type "@".

This! I indeed also believe in its potential, so let's keep that option open for the future.

Comment 3

[Marco Bonardo [:mak]]

Drew pointed out that we already add whitespace for shortcuts, so nvm that part of my comment.
It still sounds like a good opportunity for the future. One thing I'd really like is if one day we remove the highlight hack and actually convert it to a real html box before the input box (so that I can put the bar in @bookmarks or @amazon mode and it persists until I backspace or close that box). Or anyway I'd like us to stop using highlight hacks and if we have a specific enabler it *should* be easier.

Comment 4

[Drew Willcoxon :adw]

Attachment: Bug 1504847 - Disable search shortcut highlighting etc. for non-@ shortcuts

This is based on the patch in bug 1504552.  I'm calling the @engine aliases -- as opposed to aliases without @ -- "token" aliases since I need to refer to them somehow.

Comment 5

[Drew Willcoxon :adw]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2198db4e261a231a70a6ccda80217fe9502f78f1

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ed07f7e5cf44
Disable search shortcut highlighting etc. for non-@ shortcuts r=mak

Comment 7

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/ed07f7e5cf44

Comment 8

[Smylers]

Please can we have a release note for this? After upgrading to Firefox 65 Beta, I initially thought my keyword searches weren't working (or I was misremembering my keywords, or they hadn't sync-ed from another device), because the highlighting wasn't showing on them.

And then when I discovered it was just the highlighting which had gone, it took some searching to find this Bugzilla entry to establish that it's an intentional change, not a bug.

A release note would've avoided thinking something had broken. It looks like 65 is still in beta, so hopefully there's time before it's final release.

Also:

In reply to Drew Willcoxon :adw from comment #0)

Users can prefix their custom keywords with @ to get
them to behave like the built-in @ shortcuts.

This doesn't appear to be the case for keywords added with right-clicking and ‘Add a Keyword for this Search...’, which until this change were being highlighted as keywords just fine.

If go to ‘One-Click Search Engines’ in Preferences and change a keyword there to start with an ‘@’, then the highlighting is restored. But for custom searches created with right-clicking, even picking a keyword that starts with ‘@’ isn't showing any highlighting. That massively restricts the ability of users to have keywords “behave like the built-in @ shortcuts”.

I've read through the above comments and the only intention seems to be to distinguish behaviour between @ and non-@ keywords, not also on how the keywords are added.