Linkit Link field: Double-encoded file links

I was just trying out this patch and noticed that if there isn't a value passed to the urldecode function on line 220, it will give an error message about a required parameter. I suggest adding the following:
$value['uri'] = $uri ? urldecode($uri) : ''; or $value['uri'] = $uri ? urldecode($uri) : NULL; - I haven't dug too deep into if the $value['uri] needs to be an empty string or a NULL.

Here's a patch with the fix mentioned, encountered this issue with a site where we got a deprecation warning that passing NULL as parameter #1 to urldecode() triggers a deprecated warning, so checking to ensure it's not empty would be important.

I ran into similar problems when users would paste URLs with spaces in them to PDFs in the file system.

With the core link widget, when pasted, a link like http://www.example.com/sites/default/files/file name.pdf would be stored as http://www.example.com/sites/default/files/file%20name.pdf. When viewed, such a link would work fine.

With the linkit widget, that same link would be stored as base:/sites/default/files/file%20name.pdf. When viewing, the links would be double-encoded, e.g. http://www.example.com/sites/default/files/file%2520name.pdf.

From that I assume that the base: and internal: link schemes must expect non-urlencoded paths.

Here's a patch that applies to 6.1.x and targets only the base: and internal: links.

Hi, I believe this is not only Media file links but any url with special characters

I added this link www.tewhatuora.govt.nz/publications?start=0&publications-topic=Antenatal...
when using LinkIt and the "External Link" option, it changes the & to &

Where as, if I add the link and press enter (to accept whatever I've typed, without selecting the External Link suggestion, it shows the correct link format

www.tewhatuora.govt.nz/publications?start=0&publications-topic=Antenatal+and+newborn+screening            << Correct
www.tewhatuora.govt.nz/publications?start=0&amp;publications-topic=Antenatal+and+newborn+screening   << Incorrect

Is this the same issue, or should I make new one?

I think it would be good to add test coverage for this so that this use case is accounted for during subsequent code changes. I am happy to work on that when I have a chance, but if anyone else wants to take that on, that'd be appreciated!