Jump to content

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


gotofritz2

Recommended Posts

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

https://www.deepl.com/translator/{query}

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.

https://www.deepl.com/translator#de/en/{query}

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
Share on other sites

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
Share on other sites

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
Share on other sites

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
Share on other sites

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

Cheers,

Andrew

 

 

Link to comment
Share on other sites

×
×
  • Create New...