New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spaces in mailto: links #74

Closed
manuelcabral opened this Issue Apr 9, 2013 · 9 comments

Comments

Projects
None yet
2 participants
@manuelcabral

manuelcabral commented Apr 9, 2013

The spaces in mailto: links are being displayed as "+" characters in Thunderbird. Removing the .replace(/%20/g, '+') from URI.encodeQuery() solves the problem, but it guess it must be there for a reason.
I'm currently using a fork of the repository where this line is removed. Would it be useful to somehow add an option to perform the encoding without replacing spaces by + characters?

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Apr 9, 2013

Member

Can you also check this behavior for other mail clients (such as Outlook and whatever people use)? Mail.app (default mail client on Mac OS X) behaves like you described %20 is ok, + is taken literally. Testcase

Member

rodneyrehm commented Apr 9, 2013

Can you also check this behavior for other mail clients (such as Outlook and whatever people use)? Mail.app (default mail client on Mac OS X) behaves like you described %20 is ok, + is taken literally. Testcase

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Apr 9, 2013

Member

Ok, so far Mail.app, Outlook, Thunderbird require %20, GMail will accept both (probably because it's a webapp…) any other clients one would want to check?

Member

rodneyrehm commented Apr 9, 2013

Ok, so far Mail.app, Outlook, Thunderbird require %20, GMail will accept both (probably because it's a webapp…) any other clients one would want to check?

@manuelcabral

This comment has been minimized.

Show comment
Hide comment
@manuelcabral

manuelcabral Apr 9, 2013

I got the same results in GMail and Mail.app. Here are some email client statistics: http://www.campaignmonitor.com/resources/will-it-work/email-clients/ . I don't have any other client here, but I can try hotmail and yahoo later.

manuelcabral commented Apr 9, 2013

I got the same results in GMail and Mail.app. Here are some email client statistics: http://www.campaignmonitor.com/resources/will-it-work/email-clients/ . I don't have any other client here, but I can try hotmail and yahoo later.

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Apr 9, 2013

Member

So, this would call for different encodeQuery() behavior depending on protocol. I'm not sure how cool that really is. The problem is that the protocol can be changed after modifying the query string (which causes the de/encoding), like URI('?subject=foo+bar').protocol('mailto').toString()

Maybe we can introduce a protocol hook. It would be called every time the protocol is touched. That would allow switching the encoding states (for further modification) and trigger a de/encode to convert + to %20 and vice versa.

(just noting thoughs…)

Member

rodneyrehm commented Apr 9, 2013

So, this would call for different encodeQuery() behavior depending on protocol. I'm not sure how cool that really is. The problem is that the protocol can be changed after modifying the query string (which causes the de/encoding), like URI('?subject=foo+bar').protocol('mailto').toString()

Maybe we can introduce a protocol hook. It would be called every time the protocol is touched. That would allow switching the encoding states (for further modification) and trigger a de/encode to convert + to %20 and vice versa.

(just noting thoughs…)

@manuelcabral

This comment has been minimized.

Show comment
Hide comment
@manuelcabral

manuelcabral Apr 9, 2013

Would it also be possible to convert the spaces when the data is read, and check then what the protocol is?

manuelcabral commented Apr 9, 2013

Would it also be possible to convert the spaces when the data is read, and check then what the protocol is?

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Apr 9, 2013

Member

nope. The example URI('?subject=foo+bar').protocol('mailto').toString() should've proven that. But I guess we could hook things into .normalize() and clean things up there. Trouble is, you'd have to call that method every time just to make sure you've got the right encoding.

Member

rodneyrehm commented Apr 9, 2013

nope. The example URI('?subject=foo+bar').protocol('mailto').toString() should've proven that. But I guess we could hook things into .normalize() and clean things up there. Trouble is, you'd have to call that method every time just to make sure you've got the right encoding.

rodneyrehm added a commit that referenced this issue Aug 3, 2013

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Aug 3, 2013

Member

I've fixed this in master - it will be included in the next release. thank you for your help!

Member

rodneyrehm commented Aug 3, 2013

I've fixed this in master - it will be included in the next release. thank you for your help!

@rodneyrehm rodneyrehm closed this Aug 3, 2013

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Aug 3, 2013

Member

You can now make a URI instance escape spaces with %20 rather than + by calling .escapeQuerySpace(false) - that should help. It doesn't cover converting from one to the other, though!

Member

rodneyrehm commented Aug 3, 2013

You can now make a URI instance escape spaces with %20 rather than + by calling .escapeQuerySpace(false) - that should help. It doesn't cover converting from one to the other, though!

@manuelcabral

This comment has been minimized.

Show comment
Hide comment
@manuelcabral

manuelcabral commented Aug 4, 2013

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment