Allow customizing or disabling the "cs" keyword used for omnibox functionality

[moosdev]

Currently the cs keyword used for omnibox functionality (described in the readme, chapter 3.6 here) seems to be hardcoded.

At least I couldn't find any option to customize or disable it in the extension settings (advanced settings included; but maybe I missed or overlooked it).

I even tried setting the value in Omnibox > Search Action > Omnibox to No Action (in the extension settings), thinking it may disable the this functionality altogether, but that doesn't alleviate the problem either.

I think there should be an explicit option to disable and/or customize this functionality (i.e. changing the cs keyword to something else).

As it is now, one unfortunate consequence is that it overshadows search terms that begin with "cs ", e.g. "cs go" or "cs education".

I wondered if there was already an (open/closed) issue for this, but haven't found any (but I only used "omnibox" as a search term, maybe that wasn't thorough enough). If there is, I'd be happy to be pointed to it!

EDIT: I'm on version 1.39 of the extension, and I'm using Firefox 100.0.1

[ssborbis]

Unfortunately, the omnibox keyword is set in the manifest; essentially hardcoded. And there's no way to really disable it.

I'm thinking about workarounds

1. Disable searches beginning with 'cs' ( type 'cs go', press enter, nothing happens )
2. Process 'cs' prefixed searches through this addon, but treat 'cs' as part of the search ( 'cs go' actually searches 'cs go' )

[moosdev]

Thank you for the reply!

Yes, the "cs" keyword in the manifest was also the only place I found when sporadically github-searching through the codebase.

As for the suggested workarounds:

1. Disable searches beginning with 'cs' ( type 'cs go', press enter, nothing happens )

At least on Firefox, this is already the current behaviour. After pressing enter, the url bar returns to it's previous state: If the url bar is populated with text, it gets selected (like it is when you press ctrl+l to focus it), if was empty beforehand it's empty again now, with the caret at the start and all. Also, I wouldn't consider it a workaround since it effectively excludes searchable phrases from being searched (that are not too far-fetched or unreasonable).

2. Process 'cs' prefixed searches through this addon, but treat 'cs' as part of the search ( 'cs go' actually searches 'cs go' )

After some thought, I think that's a feasible workaround, but I feel it's still a cumbersome approach. "cs go" as a search term is a good example for this: What if a user as set "go" as a omnibox keyword for one of their search engines (i.e. google)?

I guess you will have to check against all defined keywords and/or hotkeys configured in the search engine manager anyway. If nothing matches, then propagate it to the browsers default search engine, "cs" included. So in the end, that would be more of a user error (as users should know if they set "go" as one of their omnibox keywords, and the consequences that come with it), so it's fine.

And, is it really not possible to disable this? Or rather, abort from further processing a search term beginning with "cs"? I would assume the input after "cs" gets processed somewhere in the extension's code. At this point, after checking some user-configurable flag (ala "OmnibarEnable"), can't you just conditionally abort further processing and send the input back to the browser search, with "cs" prefixed? This would be kind of a roundtrip, but the search term would at least end up at the user-preferred place depending on the flag and get processed correctly. But maybe that's not possible with what the extension APIs allow and/or how the extension is set up.

I think "cs" as a keyword is too "aggressive" in the first place. I'm a fan of DuckDuckGo bangs so I'd welcome it if the keyword starts with a "!". But that's just me. Unfortunately this too clashes, but now with a DuckDuckGo bang ("!cs" is a registered bang for cheapshark.com). So maybe another symbol?

The problem is also informing all the extension users of the keyword change, whatever it would be changed to. And also dealing with users who disagree with this change.

I also realized that I misunderstood the "omnibox keyword" functionality in the search engines manager. I was under the impression that they work by themselves, but apparently they are only active if prefixed with the "cs" keyword. (I don't use this feature at all.) I would have suggested to register some kind of internal/behind-the-scenes ContextSearch search engine itself as a search engine in the search engine manager (with the default omnibox keyword being "cs"). I haven't looked too much through the codebase, maybe something similar like this is done already. With that, you can then probably leverage some existing functionality that other search engines in the extension have (disabling, keyword change, etc.), which would solve the problem. I don't know exactly why I'm mentioning those two things together, I probably felt they are kind of related. I'm leaving this less succinct paragraph in, maybe something can be gleaned from this.

So I think your second workaround is reasonable and doesn't seem too expensive or difficult to implement, given there's a data structure containing the configured keywords already somewhat present. I'd appreciate the change in some future release.

In the meantime I might look into changing the manifest.json locally (pre-edit, after some short research: I see it's probably more difficult or impossible to do this in Firefox), or write out "cs" explicitly if I want to search it (e.g. "compsci" or "computer science").

[ssborbis]

It does seem like the devs should have added a way to disable the omnibox via the API, but here we are. If you were on chrome it wouldn't be such a big deal, because you could just edit the manifest and load the code unpacked ( which persists over browser sessions ).

I added omniboxPseudoDisabled to the Advanced -> Manual Edit prefs. Set to true and it should run "cs"-prefixed searches through this addon, but retain the prefix in the search. The engine it uses will be the first search engine in the search engines manager. Code is the development branch if you want to test.

[moosdev]

Sorry for the late update, I only got around to test this today.

I've tested after I loaded the development branch (commit 05e5ec7), via the procedure described here. (I removed the extension that was installed via addons.mozilla.org, to avoid conflicts&co)

I changed omniboxPseudoDisabled to true. In all scenarios, the first configured engine is google.com, the default that comes with the extension. The omniboxSearch setting is set to openBackgroundTab. All other settings and search engines are default, as far as I can tell. I'll list what I expected to happen, and then the current behaviour. I'll only include those cases, where my expecations differed from the results. I haven't tested all "combinations", so this isn't comprehensive.

1.
input: "cs x"
expected: google opens with "cs x" as search term
current: nothing happens (same as OP behaviour)

I suspect this has to do with the fact that no search engine has an omnibox keychar set by default. So I set the omnibox keychar for the first default engine (google.com) to "a"

2.
input: "cs a x"
expected: google opens with "cs a x" search term
current:  google opens with "cs x" search term

note: I think the general condition for the previous case is, that the the second search-term contains some configured omnibar keychars

3.
input: "cs y x"
expected: google opens with "cs y x" search term
current:  nothing happens (same as OP behaviour)

note: "y" is not a set omnibox keychar in the previous case, "y" could also be a string, same behaviour, given it doesn't contain omnibar keychars, as in case 2.

I remove the "a" keychar from the first engine and set omnibox keychar for the second default engine (amazon.com) to "b". The first engine is still google.com. I agree with your decision of it using the first in the list of configured search engines.

4.
input: "cs x"
expected: google opens with "cs x" search term
current:  amazon opens with "cs x" search term

5.
input: "cs b x"
expected: google opens with "cs b x" search term
current:  amazon opens with "cs x" search term

note: see case 2

6.
input: "cs y x"
expected: google opens with "cs y x" search term.
current:  nothing happens (same as OP behaviour)

note: see case 3

[ssborbis]

Fixes in the repo now.

Hotkeys should be ignored, and you shouldn't need to set one ( it will simply use the first engine in your tree )

[moosdev]

(Sorry, currently only have time on the weekends to sit down and check out the updates. Anyway: ) Looks and works great on my end! I hope it gets merged into master (and updated in the AMO) in one of the next future releases. Thank you very much for the quick and great support! From my side, this issue can be closed now, which I'll leave up to you.

[rediffusion]

@moosdev What's AMO here?

(and updated in the AMO)

[moosdev]

@rediffusion

@moosdev What's AMO here?

(and updated in the AMO)

abbreviation for addons.mozilla.org Basically I was referring to the Mozilla Firefox equivalent of the Chrome Web Store :) But maybe it was too obtuse or outdated to refer to it that way

EDIT: It also didn't help that I probably used a wrong preposition. Maybe "on (the) AMO" would've communicated it better in any case.