Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be able to disable "Searching for emojis [...] is disabled" in address/search bar #139

Open
Exagone313 opened this issue Oct 5, 2022 · 6 comments
Labels
blocked Cannot be resolved, because we need to wait for something else to be resolved first. enhancement New feature or request

Comments

@Exagone313
Copy link

Background

When I try to search for keywords starting by emoji and press enter, it redirects me to this addon preferences and I loose my search keywords. My current workaround is to never put emoji as a first keyword, which is not desired (since the first keyword usually has a greater weight in search engines).

22-10-05-11-11-05-414725361

Proposed solution

Do not ask to enable this option when it is disabled.

Alternatives

  • Add an option to disable this behavior in the preferences
  • Only ask to enable it the first time

Additional context

Integration is disabled:

22-10-05-11-15-11-703704373

@Exagone313 Exagone313 added the enhancement New feature or request label Oct 5, 2022
@rugk
Copy link
Owner

rugk commented Oct 5, 2022

Yeah, I would also have liked that. Unfortunately, the keyword that triggers the search needs to be statically defined. See:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/user_interface/Omnibox#specifying_the_omnibox_customization

In our case, it is emoji:

"keyword": "emoji"

I also doubt Mozilla will change this, as dynamically changing the keyword could be abused to intercept (all) search queries
(e.g. changing it to each letter of the alphabet or so).

So unfortunately, I have to say this issue is blocked, and I cannot really do anything here.

Alternative solutions

    • Use a less common keyword, which would less likely to be a problem in "usual search" when disabled.
      Problems: Would break existing user workflows and if the feature is desired a common keyword is really useful. (Given that if you just have to think about the keyword you need to enter it is possibly faster to use a real web search or so.)

@rugk rugk added the blocked Cannot be resolved, because we need to wait for something else to be resolved first. label Oct 5, 2022
@Exagone313
Copy link
Author

Exagone313 commented Oct 5, 2022

@rugk In my case I could report this as a bug to Firefox, since I already entered a keyword (for a search engine). Though since they introduced search keyword being displayed differently than bookmark and add-on keywords, there is a difference in behavior. I'll need to make more tests before reporting.

Also I have keyword.enabled=false, it may be responsible to this behavior (it is not fully supported).

I don't mind hacking my own Firefox for my own usage, I have experience on (and the CPU/memory for) building Firefox.

@tdulcet
Copy link
Contributor

tdulcet commented Oct 5, 2022

In my case I could report this as a bug to Firefox, since I already entered a keyword (for a search engine).

Yeah, I would agree that this is a Firefox bug, as users should not be able to use multiple keywords at once. Please do report it to them if you can.

the keyword that triggers the search needs to be statically defined

See bug 1375453 for allowing the user to change the keyword. There are actually a lot of known issues with this feature, including that it does not work in private windows (bug 1779400) and it can only show a fixed number of suggestions (bug 1375252).

@rugk
Copy link
Owner

rugk commented Oct 19, 2022

Yeah, I would agree that this is a Firefox bug, as users should not be able to use multiple keywords at once. Please do report it to them if you can.

Did you find the time to do this, @Exagone313? I totally agree, multiple keywords is not really useful/should not be possible.

@Exagone313
Copy link
Author

Did you find the time to do this, @Exagone313?

I didn't, but thanks for reminding me. 😅

@Exagone313
Copy link
Author

I just created it: https://bugzilla.mozilla.org/show_bug.cgi?id=1796788

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Cannot be resolved, because we need to wait for something else to be resolved first. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants