[GH-ISSUE #126] [BUG] Whoogle won't search right from the address bar #91

Closed
opened 2026-02-25 20:34:52 +03:00 by kerem · 6 comments
Owner

Originally created by @cammelspit on GitHub (Sep 25, 2020).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/126

Describe the bug
When I have my Whoogle site set to be the default search engine, I type in a search term and instead of searching for that term, it just opens my Whoogle but the search term simply is not passed along.

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'https://search.exampleurl.net'
  2. Click on '
    image
    '
  3. Change the search setting '
    image
    '
  4. Search antyhing in the search bar
  5. Greeted with the main Whoogle page without the search term typed in.

Deployment Method

  • Heroku (one-click deploy)
  • Docker
  • run executable
  • pip/pipx
  • Other: [describe setup]

Version of Whoogle Search

  • Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc)
  • Version 0.2.0
  • Not sure
    image

Desktop (please complete the following information):

  • OS: [W10 Latest build]
  • Browser [FireFox]
  • Version [e.g. 22]

Additional context
I have just today done a full reset of my OS, and this install of Firefox is as of now only a few hours old. I know it worked before but I don't know if it stopped recently (in the last couple of days) and I didn't notice or if it is exclusively an issue with my new OS install as I have been very busy with work and haven't really had the chance to notice.

Originally created by @cammelspit on GitHub (Sep 25, 2020). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/126 **Describe the bug** When I have my Whoogle site set to be the default search engine, I type in a search term and instead of searching for that term, it just opens my Whoogle but the search term simply is not passed along. **To Reproduce** Steps to reproduce the behavior: 1. Go to 'https://search.exampleurl.net' 2. Click on ' ![image](https://user-images.githubusercontent.com/9344114/94214838-901fc100-fe8f-11ea-98f1-57e49a32ebed.png) ' 3. Change the search setting ' ![image](https://user-images.githubusercontent.com/9344114/94214873-ad548f80-fe8f-11ea-99cf-aaa5aab5a8c6.png) ' 4. Search antyhing in the search bar 5. Greeted with the main Whoogle page without the search term typed in. **Deployment Method** - [ ] Heroku (one-click deploy) - [X] Docker - [ ] `run` executable - [ ] pip/pipx - [ ] Other: [describe setup] **Version of Whoogle Search** - [ ] Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc) - [X] Version 0.2.0 - [ ] Not sure ![image](https://user-images.githubusercontent.com/9344114/94214734-3919ec00-fe8f-11ea-91c8-88dbb379ea50.png) **Desktop (please complete the following information):** - OS: [W10 Latest build] - Browser [FireFox] - Version [e.g. 22] **Additional context** I have just today done a full reset of my OS, and this install of Firefox is as of now only a few hours old. I know it worked before but I don't know if it stopped recently (in the last couple of days) and I didn't notice or if it is exclusively an issue with my new OS install as I have been very busy with work and haven't really had the chance to notice.
kerem 2026-02-25 20:34:52 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@cammelspit commented on GitHub (Sep 25, 2020):

I don't know if this is what I did before to get it working because it's been long enough since I set up Whoogle that I genuinely can't recall. I was able to work around the issue by using THIS PLUGIN and just manually entering the string like you would for the mobile browser since the desktop Firefox can't do this normally for some silly reason.

So, I am happy again! LOVE Whoogle and I use it everywhere, I even use my Whoogle at work because it's all nice and exposed with a reserve proxy and SSL. Super slick, love it, keep doing excellent work!

<!-- gh-comment-id:698730943 --> @cammelspit commented on GitHub (Sep 25, 2020): I don't know if this is what I did before to get it working because it's been long enough since I set up Whoogle that I genuinely can't recall. I was able to work around the issue by using [THIS PLUGIN](https://addons.mozilla.org/en-US/firefox/addon/add-custom-search-engine/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search) and just manually entering the string like you would for the mobile browser since the desktop Firefox can't do this normally for some silly reason. So, I am happy again! LOVE Whoogle and I use it everywhere, I even use my Whoogle at work because it's all nice and exposed with a reserve proxy and SSL. Super slick, love it, keep doing excellent work!
Author
Owner

@benbusby commented on GitHub (Sep 30, 2020):

That's interesting, I actually just randomly had this happen to me yesterday. For me it only happened once though, and all subsequent searches were forwarded to the correct endpoint. I'll try and do some testing with a debug build and see if I can reproduce it, but my initial impression is that it might be an issue either with the opensearch.xml template or with Firefox itself. It's bizarre either way though.

<!-- gh-comment-id:701409935 --> @benbusby commented on GitHub (Sep 30, 2020): That's interesting, I actually just randomly had this happen to me yesterday. For me it only happened once though, and all subsequent searches were forwarded to the correct endpoint. I'll try and do some testing with a debug build and see if I can reproduce it, but my initial impression is that it might be an issue either with the `opensearch.xml` template or with Firefox itself. It's bizarre either way though.
Author
Owner

@sutidor commented on GitHub (Nov 26, 2020):

Same issue here when I use nginx reverse proxy.

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app whoogle-search;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }

When I use plain whoogle http on port 5000 it does work. And if I use postman and POST q=123 on the URL I find in opensearch.xml it does work, too!

Any idea how to fix? Thx in advance

Update: I tried to set the option for "use GET only" on the main page, and it changes the opensearch.xml apparently, but the issue persists.

<!-- gh-comment-id:734465722 --> @sutidor commented on GitHub (Nov 26, 2020): Same issue here when I use nginx reverse proxy. ``` location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app whoogle-search; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } ``` When I use plain whoogle http on port 5000 it does work. And if I use postman and POST q=123 on the URL I find in opensearch.xml it does work, too! Any idea how to fix? Thx in advance Update: I tried to set the option for "use GET only" on the main page, and it changes the opensearch.xml apparently, but the issue persists.
Author
Owner

@sutidor commented on GitHub (Nov 30, 2020):

Solution

(I modified openxml according to ecosia's)

In the docker image the path is app/templates/opensearch.xml

<?xml version="1.0" encoding="utf-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
                       xmlns:moz="http://www.mozilla.org/2006/browser/search/">
  <ShortName>Whoogle</ShortName>
  <Description>Whoogle: A lightweight, deployable Google search proxy for desktop/mobile that removes Javascript, AMP links, and ads</Description>
  <InputEncoding>UTF-8</InputEncoding>
  <Image width="60" height="60" type="image/png"> data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADwAAAA8CAYAAAA6/NlyAAAABGdBTUEAALGPC/xhBQAAAAFzUkdCAK7OHOkAAAAgY0hS$
  <Url type="text/html" method="get" template="{{ main_url }}/search?q={searchTerms}"></Url>
  <Url type="application/x-suggestions+json" template="{{ main_url }}/autocomplete?q={searchTerms}"></Url>
  <moz:SearchForm>{{ main_url }}/search</moz:SearchForm>
</OpenSearchDescription>

For those who are interested, the difference is the kind of request. It formerly used params like so <Param name="q" value="{searchTerms}"/> + POST by default. Now I default to GET and moved everything directly to the querystring ?q={searchTerms}.

<!-- gh-comment-id:735826159 --> @sutidor commented on GitHub (Nov 30, 2020): ### Solution (I modified openxml according to ecosia's) In the docker image the path is app/templates/opensearch.xml ``` <?xml version="1.0" encoding="utf-8"?> <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/"> <ShortName>Whoogle</ShortName> <Description>Whoogle: A lightweight, deployable Google search proxy for desktop/mobile that removes Javascript, AMP links, and ads</Description> <InputEncoding>UTF-8</InputEncoding> <Image width="60" height="60" type="image/png"> data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADwAAAA8CAYAAAA6/NlyAAAABGdBTUEAALGPC/xhBQAAAAFzUkdCAK7OHOkAAAAgY0hS$ <Url type="text/html" method="get" template="{{ main_url }}/search?q={searchTerms}"></Url> <Url type="application/x-suggestions+json" template="{{ main_url }}/autocomplete?q={searchTerms}"></Url> <moz:SearchForm>{{ main_url }}/search</moz:SearchForm> </OpenSearchDescription> ``` For those who are interested, the difference is the kind of request. It formerly used params like so `<Param name="q" value="{searchTerms}"/>` + POST by default. Now I default to GET and moved everything directly to the querystring `?q={searchTerms}`.
Author
Owner

@benbusby commented on GitHub (Nov 30, 2020):

Interesting. The amount of issues that the opensearch format causes has been pretty annoying. I've found in the past that if parameters weren't given their own element (i.e. <Param name=...), then browsers like Chrome would reject the template altogether. Likewise if the method tag is declared at all (regardless of value) then Chrome will reject the template again. The solution that is currently in place on the develop branch/beta tag is to remove the method declaration if the user is using Chrome, and I haven't had any issues with the current implementation on any browser that I've tested.

<!-- gh-comment-id:735918323 --> @benbusby commented on GitHub (Nov 30, 2020): Interesting. The amount of issues that the opensearch format causes has been pretty annoying. I've found in the past that if parameters weren't given their own element (i.e. `<Param name=...`), then browsers like Chrome would reject the template altogether. Likewise if the `method` tag is declared at all (regardless of value) then Chrome will reject the template again. The solution that is currently in place on the develop branch/beta tag is to remove the method declaration if the user is using Chrome, and I haven't had any issues with the current implementation on any browser that I've tested.
Author
Owner

@benbusby commented on GitHub (Jan 14, 2021):

I think I'm going to close this one for now, as it doesn't seem to be easily replicated on Firefox or Chrome on my end. As of github.com/benbusby/whoogle-search@a519de90af this should've been completely fixed for Chrome, but if not, I'll open a new issue and investigate the opensearch formatting a bit further.

<!-- gh-comment-id:760530461 --> @benbusby commented on GitHub (Jan 14, 2021): I think I'm going to close this one for now, as it doesn't seem to be easily replicated on Firefox or Chrome on my end. As of https://github.com/benbusby/whoogle-search/commit/a519de90af39fb3825b4699cda70155f421ddfc8 this should've been completely fixed for Chrome, but if not, I'll open a new issue and investigate the opensearch formatting a bit further.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/whoogle-search#91
No description provided.