User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170303084134 Steps to reproduce: Open https://en.wikipedia.org/wiki/Dirk_Gently%27s_Holistic_Detective_Agency Alternative URL: https://example.com/%27 Copy URL from address bar. Paste into search bar, input box, or external application. Actual results: URL is not percent encoded: https://en.wikipedia.org/wiki/Dirk_Gently's_Holistic_Detective_Agency https://example.com/' Expected results: URL is percent encoded: https://en.wikipedia.org/wiki/Dirk_Gently%27s_Holistic_Detective_Agency https://example.com/%27 Note that this does not occur in query strings. For example, this page is correctly percent encoded: https://en.wikipedia.org/w/index.php?title=%27&redirect=no Percent encoding apostrophes is encouraged by RFC 3986, where they are listed as "sub-delims". https://tools.ietf.org/html/rfc3986#section-2.2 As a practical matter, this breaks copying and pasting URLs from the address bar into other applications like email, IRC chat, etc. Reproducibility of this bug may depend on operating system. I have reproduced on several Linux machines, but reproducibility on Windows is less clear.
WFM in Fx52, 53.0a2 (2017-03-03) and 54.0a1 (2017-03-03) on Win10.
Has STR: --- → yes
Component: Untriaged → Location Bar
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
WFM with FF53 on Win 7. Ciprian, could you check if if it's secific to the Linux version?
User Agent Mozilla/5.0 (X11; Linux i686; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID 20170305110158 WFM on Ubuntu 14.04 x32 & x64 on the latest Release (51.0.1), Aurora (53.0a2) and Nightly (54.0a1).
The first time I reproduced this bug, I was using Firefox 45.7.0 (the version in Debian Jessie and the basis for Tor Browser). It is fully reproducible in this version (on Linux, anyway). View Page Info and window.location.href show the URL as percent encoded, but this doesn't transfer to copy and paste. It seems I fooled myself into "reproducing" this bug in Firefox 53.0 because I had sync enabled, so the unencoded URL was already in my history. So the steps to reproduce should have read: - Open https://en.wikipedia.org/wiki/Dirk_Gently%27s_Holistic_Detective_Agency - Copy URL from address bar. - Paste back into address bar and press enter to reload page, loading the encoded URL but storing the unencoded URL in history. - Copy URL from address bar. - Paste back into address bar and press enter to reload page, loading the unencoded URL. - Copy URL from address bar. - Paste into search bar, input box, or external application. URL is not encoded anymore. I have reproduced this in a blank profile on Firefox 53.0, but I would hesitate to call this behavior a bug. Changing it would probably be more of a feature request, and an awfully specific one at that. As reported, this bug is only reproducible in Firefox 45.7.0, not in Firefox 53.0. As such, this bug report should probably be closed as invalid.
I can't reproduce it in Fx45.7.0 and 48.8.0 too, on Win10, with comment 4. Per comment 4 & https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla/What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs_as_WORKSFORME, close as WFM.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
If we open unencoded URLs such as https://en.wikipedia.org/wiki/Dirk_Gently's_Holistic_Detective_Agency and copy the URL from the location bar, they will stay unencoded. But we should not encode them because we can't tell whether they are used as a delimiter or not. > Percent encoding apostrophes is encouraged by RFC 3986, > where they are listed as "sub-delims". This is a common misunderstanding of the spec. Authors should percent-encode apostrophes if they intended to use them as data, but it does not mean UAs should automatically percent-encode them. Rather, automatic encoding will make it impossible to use them as delimiter as the spec intended.
You need to log in before you can comment on or make changes to this bug.