Jump to content

Cannot pass strings with # to web search if url itself contains #, or if string has more than one #

Recommended Posts

1. Set up a web search with the following URL:


2. Don't bother testing it; the test works, the issue is when you run it for real

3. Quit Alfred Preferences and call up the search  three times, with each of the following strings in turn

1 -> ich mag alfredapp
2 -> ich mag #alfredapp
3 -> ich #mag #alfredapp

4. In cases 1. and 2. a web browser is opened and everything works as expected (nothing appears in the browser, but that's because the URL is wrong). In case 3. nothing happens; the browser doesn't respond

5. Change the web search URL to this, and try again both searches from point 3.


6. Note that only 1) works. 2) and 3) don't fire up the browser.


It looks like Alfred pre-validates the string and decides that if there is more than one # it is an invalid URL and gives up



Link to comment

I’m not sure Alfred can do anything about this.


A # is perfectly valid in a URL, but you actually need it to be encoded to %23 because it’s part of the URL path in your case, not a URL fragment.


But Alfred has no way of knowing that.  It can’t handle both those situations correctly, and the fragment case (which Alfred assumes) is far more common. 


I think you’ll have to create your own URL encoded the way DeepL wants and the just ask Alfred to open {query}.

Link to comment
On 6/13/2021 at 1:37 AM, deanishe said:

I think you’ll have to create your own URL encoded the way DeepL wants and the just ask Alfred to open {query}.


I don't think you get it. If there are two #s in the url, Alfred doesn't launch the browser. It's not simply that the string is encoded wrong; we never get as far as that. I suspect Alfred validates strings, and if it thinks they are "wrong" it gives up. But it shouldn't. 


Link to comment
2 hours ago, gotofritz2 said:

I don't think you get it. If there are two #s in the url, Alfred doesn't launch the browser


Yes, I get it. It's not Alfred. If Alfred were rejecting your URL, it would tell you itself.


It is asking macOS to open your URL, but macOS or your browser is dropping the URL on the floor because it isn’t valid. Run this AppleScript and you’ll see the same behaviour: tell current application to open location "https://www.example.com/#hashes#/"


I figured your goal was to get your URL working, not have Alfred show you an error when your URL is invalid. So I explained why it isn't working and how to get it to work.

Edited by deanishe
Link to comment

Alfred (as of 4.3) actually has a new internal URL parser which, on quickly checking, actually handles this specific scenario correctly. This URL parser is used in most places throughout Alfred, but currently not in Custom Searches and the workflow Open URL Action, as I want it to be fully tested and verified before potentially causing a regression for a highly used "working" feature in Alfred.


URL parsing is in fact an extremely complex task to do correctly, as there are a number of assumptions which have to be made, which is why Apple's own APIs don't do it automatically. Alfred's parser splits the URL string into the relevant components, then uses Apple's NSURLComponents to construct and encode the URL.


Just as a purely "as interest" note, here is a screenshot of the internal testing tool I created to Alfred's [future] URL parser to make it easy to see that URLs were being split and parsed correctly:

Screenshot 2021-06-14 at 16.12.42.png





Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...