Brave can't handle URLs with whitespace in it

[Sh1d0w]

Did you search for similar issues before submitting this one?

Yes.

Describe the issue you encountered:
If you try to visit url, which has whitespace in it, Brave will assume you want to search via your default engine, not matter that the url starts with http or https. How I discovered this was just simply uploading an image with whitespace in it to postimage for another issue here. The generated url was this:

https://s10.postimg.org/snp1s3aah/Screenshot+from 2016-08-13 17-50-27.png

Now if you past this url in Chrome or FF they will actually visit this url, in Brave I get my default search engine queried.

I have rised a PR to fix this behaviour.

Expected behavior:
When I paste this url https://s10.postimg.org/snp1s3aah/Screenshot+from 2016-08-13 17-50-27.png in the url bar I expect to see the image.

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Every platform.
• Brave Version:
  0.11.4
• Steps to reproduce:
  1.Paste https://s10.postimg.org/snp1s3aah/Screenshot+from 2016-08-13 17-50-27.png in the url bar
  1. Hit eneter
• Screenshot if needed:
• Any related issues:

[neeklamy]

Thing is: Literal spaces aren’t allowed in URLs (source: Stack Overflow) – even that URL you posted is messed up. Spaces are typically encoded as %20, but as you can see with the URL you posted, spaces can also use the much nicer + symbol. Only, that URL gets rewritten too, so this:

https://s10.postimg.org/snp1s3aah/Screenshot+from 2016-08-13 17-50-27.png

Becomes this, where those encoded and unencoded spaces are turned into underlines:

https://s10.postimg.org/snp1s3aah/Screenshot_from_2016_08_13_17_50_27.png

I’d suggest this is more of a bug with Postimage.

[Sh1d0w]

@neeklamy I know this. But nowdays browsers are smart enough to understand when you want to visit url and when you want to search. It is not only with postimage, you can have urls with whitespaces generated from other places. As you can see if you try to load this practicular url in FF or Chrome or even Edge, it will urlencode it and will load it because there is a scheme at the begining. With brave it searches the web for the url.

My PR does exactly this. It just checks if the typed string starts with scheme to treat it like a url and not as search term. In my oppinion anything you type starting with http:// for example should be treated by the browser as a url, no? :)

[neeklamy]

Oh, agreed @Sh1d0w, that is some funny rewriting going on with that site though.

Can you confirm this doesn’t change the current whitespace trimming (I’m not familiar with how the URL bar works)? For example if you copy and paste a URL with either or both leading and trailing spaces that the whitespace is trimmed off, and we’re taken to the URL.

[Sh1d0w]

@neeklamy Yes the old behaviour is completely preserved. If you have whitespaces at the begining and the end of the url they will be trimmed. Also of you type a word or set of words, it will search the default search engine.

The only change is to check if the string starts with scheme, then Brave will be smart enough to know it is a url.

Here is the behaviour of the PR I have rised:

String typed in the url bar	Before	Now
google.com	open https://google.com	open https://google.com
test	searches for test	searches for test
test test	searches for test test	searches for test test
http://example.com/test image.jpg	searches for http://example.com/test image.jpg via default search engine	opens http://example.com/test image.jpg

[dsb22]

I am still having this problem of Brave automatically turning a url into a search term. The url I am trying to go to is "http:\cp-me-01.act.local:82" (without quotes). In Firefox, I can get to this as a url, in Brave I cannot.

[neeklamy]

I would guess Firefox rewrites that to conform to the URL spec, from the WHATWG URL Standard: URL syntax

A scheme-relative file URL must be "//", followed by one of the following

• a host, optionally followed by a path-absolute non-Windows-file URL
• a path-absolute URL.

Does this URL work? http://cp-me-01.act.local:82

[Sh1d0w]

@dsb22 http:\cp-me-01.act.local:82 is not valid url address, so Brave fallbacks to search.

If you type the url correctly e.g. http://cp-me-01.act.local:82 it will correctly try to open it.

[dsb22]

Thank you, yes, when it's changed from http:\cp-me-01.act.local:82 to http://cp-me-01.act.local:82 then it does work. 

  From: neeklamy <notifications@github.com>

To: brave/browser-laptop browser-laptop@noreply.github.com
Cc: dsb22 trinity628@yahoo.com; Comment comment@noreply.github.com
Sent: Wednesday, October 5, 2016 12:08 PM
Subject: Re: [brave/browser-laptop] Brave can't handle URLs with whitespace in it (#3167)

I would guess Firefox rewrites that to conform to the URL spec, from the WHATWG URL Standard: URL syntax
A scheme-relative file URL must be "//", followed by one of the following

• a host, optionally followed by a path-absolute non-Windows-file URL
• a path-absolute URL.

Does this URL work? http://cp-me-01.act.local:82—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[dsb22]

Hi, I control-c'd the original, which was from a company IT email.  I'll edit \ for // next time, thanks.

  From: Radoslav Vitanov <notifications@github.com>

To: brave/browser-laptop browser-laptop@noreply.github.com
Cc: dsb22 trinity628@yahoo.com; Mention mention@noreply.github.com
Sent: Wednesday, October 5, 2016 12:34 PM
Subject: Re: [brave/browser-laptop] Brave can't handle URLs with whitespace in it (#3167)

@dsb22 http:\cp-me-01.act.local:82 is not valid url address, so Brave fallbacks to search.If you type the url correctly e.g. http://cp-me-01.act.local:82 it will correctly try to open it.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.