(edit) Using the 'Add Custom Search' widget from the context menu is by far the easiest way to add new search engines to ContextSearch. Is there a reason you're adding engines by hand? If so, how would you suggest making it less cumbersome?

> Works, though cumbersome adding new own search engines. But he is going to embrace.

Which method of adding engines do you find cumbersome? Are you adding new engines via the context menu or by typing them in by hand in Options?

(edit 8-20)

Looks like using the sidebar isn't too viable right now with the API limitations
* no POST capability (no page injection for POST code, sidebar not considered a TAB)
* can't open sidebar from quick menu / toolbar search (only available to context menu searches)
* limited width unless user edits files in profile dir
* sidebar always opens on install for FF pre-62 (minor annoyance)

Maybe in the future when the API is a bit more robust I can look into it again.

(edit 8-19)
The web extensions API is limited in how sidebars can be opened. I can send search results to the sidebar, but I cannot OPEN the sidebar programmatically in some cases. This may effect usability.

(edit) I'm trying it out now. The sidebar width is limited but I've read it can be increased by making changes to userChrome.css . I can add the option to open search results in the sidebar under -- search actions -- without much additional code.

You want to open search results in the sidebar vs in a tab? Could you explain a bit more about how that would be useful to you?

> Good idea, way too complex when adding new search engines (no icon URL - no search engine ???) - ever heard of usability?

If you feel adding a new engine is complex, I don't think you're doing it correctly. Right-click a search bar on a webpage and choose 'Add Custom Search' from the menu. Click the Add button or Advanced -> Create to tweak the settings.

> (no icon URL - no search engine ???)

Currently, it does require a valid image to add a new search engine. Maybe it should interpret a blank url as using a generic icon instead of preventing the process from completing.

> ever heard of usability?

Yes I have heard of usability. In fact, most users find this add-on to be very easy to use. Maybe you should consider why you seem to be the exception.

The add-on does support internationalization. Right now there are translations for French and German. I'm always looking for contributors to translate into other languages. If anyone wishes to help, visit the support site on github and edit the files in the /src/_locales/en/ directory. (https://github.com/ssborbis/ContextSearch-web-ext/tree/native-app-support/src/_locales/en)

> By the way, if the right-click menu display position can also be customized (for example, you can choose to display the position under copy and paste), it is even better!

There is a setting for positioning the Quick Menu relative to the cursor with customizable pixel offsets. Do you mean moving the "Search for.." menu item higher in the context menu? Unfortunately, that cannot currently be done with the webextensions API

(edit) There was an issue with 1.6.3 which prevented adding a custom search engine from the 'simple' menu. That should be fixed in 1.6.3.2.

> Why search working from firefox search, but not from quick search (open main site page)?

Are you unable to open the quick menu? The quick menu and all other content scripts are blocked on addons.mozilla.org by mozilla. If you're on linux, you might need to set ui.context_menus.after_mouseup to true in about:config

> Also can edit search engine, but can't save (auto save if is, not working)?

Are you editing from the search engine manager in ContextSearch options? There should be a Save button below the form when editing a search engine. Is that not working?

> - close after search

Ready for 1.6.3

> - empty search bar after search

The current behavior is to display the last search on a per-session basis. The last search should be highlighted, ready to be replaced with the first keystroke. Closing Firefox will clear the last search from the session storage. Adding the option is trivial but I'm not sure it's necessary. Specifically, what issue are you having with the default behavior?

(edit) This was not working properly under linux. Fix ready for 1.6.3

> One thing that bothers me is that modifying the default engines; removing tracking parameters for example, results in a 'name already exist' error. Which is bizarre.

That's a definite bug that must have popped up when I added the ability to change the name. I'll fix that today.

(edit) 6-13
v1.6.0.3 should fix the problem

> 1) Javascript/Bookmarklet support.

(edit 6-15) Ready for v1.6.1

>Edit:
>Use short javascript snippets for more advanced local operations e.g. Find&Replace all instances of a word in a text box or copy and format selected text as bbcode, etc.

Are you wanting to access bookmarklets from the context menu when using the option to manage search engines via bookmarks? If you have a github account, start a new topic at the support site so I can get more info.

> 2) Search button: Save search history / always show last query
> 3) Search button: Make autocomplete optional

(edit 6-14) Ready for v1.6.1

> 4) Search button: Match browser theme

(edit 6-14) Having some problems with this one. Can't seem to get color values for built-in themes like Dark. I'll keep on it.

> 5) Search button: Support middleclick
Ready for v1.6.1

(edit v1.4.2)
Subfolders and separators for the context menu are live in beta for this release. Search engines can be organized from a bookmark folder after enabling the option and granting the Bookmarks permission.
---------------------------------------

Do you mean a tiered menu and separators in the context menu? I'll check it out.