1p Malformed URL's (no http: or https: term) [Fixed 2.8.2 b432]

[KyleKing]

- What you were doing when the issue happened

I enter the text, '1p jobsuitors' and pressed enter, which should have opened the 1password bookmark link; however, 1p stores a poorly formatted URL without the http:// or https:// term, so I get an error that no application can open the URL. However, if copy and pasted into chrome, the URL opens perfectly.

 

- Whether you were able to replicate it a second time by performing the same action

This couldn't be more consistent. It happens on any URL without the proper http:// or https://. You could probably replicate it by creating a false 1p entry and attempt to open it.

 

- Include any screenshots that might help us

See attached!

 

- Include the Alfred version & build number you are using

Alfred 2.8.2

 

- Include your OS X version

OX El Capitan: 10.11.2

 

- For completeness:

1Password - Version 5.4 (540046)

 

 

 

- Potential solution:

I wonder if a formatting step could be added to any time a URL is opened from Alfred. It would need to check for a the characters, '//' in the first 7-8 characters and if not found could prepend 'http://' (which would resolve to https:// if needed). The two edge cases being when a local file is loaded (i.e. '//' or 'file://')

 

 

(I will upload photos in the next post, but I could not find the upload attachment button? http://www.alfredforum.com/index.php?app=core&module=help&do=01&HID=6&hl=attach)

 

[KyleKing]

Here are the photos! I made a public Dropbox link and used the image from URL button, but I don't want to have these photos publicly visible for all time. Is there a way to upload the screenshots to sit only in this forum?

 

 

Edited January 9, 2016 by KyleKing

[Andrew]

 

I wonder if a formatting step could be added to any time a URL is opened from Alfred. It would need to check for a the characters, '//' in the first 7-8 characters and if not found could prepend 'http://' (which would resolve to https:// if needed). The two edge cases being when a local file is loaded (i.e. '//' or 'file://')

 

 

 

I've known about this for a while and avoided making assumptions of the missing scheme (for security), but this has prompted me to do a bit more research and you are correct... I will add the http scheme when missing for the next release

 

Cheers,

Andrew

[KyleKing]

Thank you for making such a rapid bug fix! It works perfectly now