Closed Bug 1271088 Opened 4 years ago Closed 4 years ago

network.standard-url.escape-utf8

Categories

(Firefox :: Address Bar, defect)

47 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1320061

People

(Reporter: chemist-acid, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [Workaround in comment 9])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160505125249

Steps to reproduce:

network.standard-url.escape-utf8 is set to false for me for quite a time.
Copy paste URL like https://uk.wikipedia.org/wiki/Головна_сторінка


Actual results:

What was copied and thus pasted is: https://uk.wikipedia.org/wiki/%D0%93%D0%BE%D0%BB%D0%BE%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D0%BE%D1%80%D1%96%D0%BD%D0%BA%D0%B0


Expected results:

Expected copy-paste result: https://uk.wikipedia.org/wiki/Головна_сторінка
Worked fine till a version or two on desktop. Never worked and doesn't works on Android (though it's probably to be filed as a separate bug)
WFM in Fx47b3 & 48.0a2 (2016-05-07) on Win10, with network.standard-url.escape-utf8=false.
Component: Untriaged → Networking
Product: Firefox → Core
This also works for me on beta, aurora, and nightly. Please reopen if you have more reliable steps to reproduce.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
Hi, reopening. Still does not work in 48.0b1. If it was not clear enough, it is not about just copying/pasting URL from anywhere but about copying and then pasting URL containing non-ASCII chars from location-bar. I have also heard two users who got updated to 47 on release that it got broken for them as well.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Maybe I could find a STR.
1. Paste & Go to <https://uk.wikipedia.org/wiki/> (NOT <https://uk.wikipedia.org/wiki/Головна_сторінка>). Firefox will redirect to <https://uk.wikipedia.org/wiki/Головна_сторінка>.
2. Copy & Paste the URL from the location bar.

Actual result: https://uk.wikipedia.org/wiki/%D0%93%D0%BE%D0%BB%D0%BE%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D0%BE%D1%80%D1%96%D0%BD%D0%BA%D0%B0
Expected result: https://uk.wikipedia.org/wiki/Головна_сторінка

Works with 45.2.0 ESR and broken on 47.0 and 50.0a1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Could you find a regression range using mozregression?
http://mozilla.github.io/mozregression/
Flags: needinfo?(chemist-acid)
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=81ab1a659071fb4b99852b1c611b341557f21ca4&tochange=8033efa33b55d559f6d8735f4d404435b3fbf57e

Bug 824887 - Use the current page's original URI rather than creating a new one for copying from the location bar, stop encoding parentheses explicitly. r=dolske
Blocks: 824887
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Networking → Location Bar
Keywords: regression
Product: Core → Firefox
Version: unspecified → 47 Branch
Flags: needinfo?(chemist-acid)
Flags: needinfo?(dao+bmo)
That pref will soon go away, and you should not use it.
Please note that this behaviour currently matches Chrome.
(In reply to Valentin Gosu [:valentin] from comment #7)
> That pref will soon go away, and you should not use it.

Great. I was going to say, I'm not sure why end users would touch this pref and, for that matter, why we support it in the first place.

Also, IMHO it actually makes sense that flipping the pref changes the behavior as reported here.
Status: NEW → RESOLVED
Closed: 4 years ago4 years ago
Flags: needinfo?(dao+bmo)
Resolution: --- → INVALID
OK, if not that pref than how do I get the behaviour wanted?

I am sorry, but could not care less about the behaviour of Chrome, and even less I understand why it's negative sides should be brought to FF. I do not need the URI percent encoding nor any other user I know needs it.

Now in order to copy URL normally I have to put pointer at the beginning of it, type a space char and only then copy, which is several actions + unneeded space character more than I need and want.

If there would (or is) another way to switch the unneeded percent encoding, then please kindly say me what it is (I am pretty sure that all the tips on the internet would lead to the subject preference). If no, I find it unacceptable in Unicode era, sorry.
I join the opinion of chemist-acid@yandex.ru

Before the upgrade to 47.0 it worked well during many versions. I know many users use the setting "Network.standard-url.escape-utf8 = false" to get the desired behavior. It was much convenient.
As I said, that pref is probably going away soon. Note that changing it could break websites for you.
Most people who copy the URL from the URL bar want a URL that works in other applications. If you want a URL that is user readable, then what you want is probably a different way/UI/shortcut of copying that.
Whiteboard: [Workaround in comment 9]
In most modern applications non-ASCII URLs work just as fine as only-ASCII ones. That problem indeed existed around 2009 but it does no more. Web has even gone as far as to have top level non-ASCII domains (.рф, .укр, etc.) If some applications still are unable to handle the URLs its their bugs and we are not to be concerned with it much.

Anyway we are not talking about changing the default behaviour here. Users switching the flag do understand what might go wrong if they use those URLs. But the pref is essential for many users. There will always be workarounds that's sure, but I do not see why to remove a useful feature and force people to do some trickery (or coding, but rather very few users are capable of this) in order to obtain the desired result.

Besides just readability, URLs in desired format are the only sane way to put in printed works. If one needs to type URL printed in a printed book/article he would freak out if it is several lines of percent signs and hexes what he needs to write exactly as it is written.
(In reply to Dão Gottwald [:dao] from comment #8)
> I'm not sure why end users would touch this pref
To copy normal russian text instead of %20%25 symbols, obviously (WYSIWYG principle).
This is one of the most important feature for every not English-speaking user, even if he isn't aware of the pref. You just got used that your English internets work fine.
Assuming you're English-speaking person, imagine that every url you copy turns into digits and `%`s. And you can't normally read it. Your first thought would be "where's `don't break it` button?"

> Also, IMHO it actually makes sense that flipping the pref changes the behavior as reported here.
What is reported here is that flipping the pref doesn't change the behavior.

(In reply to Valentin Gosu [:valentin] from comment #7)
> Please note that this behaviour currently matches Chrome.
This only means "one reason less to stay on Firefox".
Consider using another wording when deleting advantages over Chrome

Please, could you (everybody, ever) don't pretend you don't get obvious things while breaking really useful features (unlike new searchbar)? It's important things that worked for years. Don't pretend it's something that only causes imaginable troubles to those who intentionally flips prefs
I have this issue in firefox 47 too. Could you rollback changes for fix errors?
All russian URLs are broken now when it copied for send via IM, mailing, etc.
Duplicate of this bug: 1320061
Duplicate of this bug: 1320061
I have been hammered by this same problem for a couple of years now, and i finally found the courage & strength to report it (discouraged by the attitudes exhibited by some devs to user feedback...)

I am 110% behind the comments made by chemist-acid and arni2033, so i won't be repeating them here. I will just emphasize, in response to the only counter-argument offered by mozilla devs, that if there are any websites or applications that cannot handle UTF at this point in time, it is entirely their fault. Besides, we are not asking to make the use of non-ASCII characters the default behavior of firefox, only to make it available as an option to those who *know* what they're doing when they ask for it.

Mozilla has received lots of positive feedback for their recent versions, but i am really disappointed to see this bug, which should be easy to fix, germinate for 2 years now. I think mozilla is too important a project to just ignore it when it goes to an obviously wrong direction, hence this comment. Thanks for your time.
Someone can easily create an extension that can unescape the URL in the exact way that you want it and copy it to the clipboard when you press a button.
Thanks for the reply, Valentin. As i am sure you know, extensions are not without problems. So what is the technical reason for excluding this functionality when about half the world population uses non-ASCII alphabets?
(In reply to orionbelt2 from comment #21)
> Thanks for the reply, Valentin. As i am sure you know, extensions are not
> without problems. So what is the technical reason for excluding this
> functionality when about half the world population uses non-ASCII alphabets?

Well, I agree that there are limitations to webextensions, but adding a pref is even more limited. The way we implement things behind a pref might not please everybody, and the fact that something is behind a pref makes it 1. difficult to discover; 2. hard to know when it breaks.
The thing with URLs is that they're not made to be easily read. That's why Firefox copies the exact URL that it loads, not a nice easy to read variant. If we want something that's easy to read, then there's no reason we can't use a webextension for that.
Regarding your point 1, my experience is that if i look for a "foo bar" feature in firefox, typing "firefox foo bar" in a search engine will return a good answer in the top few results, including a reference to a pref if that's the way to get the feature. This is no worse than typing "foo bar" in the search field of the webextension tool.

I could also add here the complaint of numerous users that the dumbing down of the preferences GUI is one reason why prefs have become difficult to discover: They are lots and lots of them in about:config, the more important ones are buried in the ocean of the less important ones, and there is no way to distinguish them.

As for your point 2, i am not sure i follow either. Are prefs harder to know when they break because there are so many of them? I'd think that most "typical" users change no more than, say, a dozen prefs, from their default values, which is comparable to the number of webextensions they might have.

Either way, i'd think that there's much less important config options in the prefs than the option to use UTF. And i suspect that the decision of whether to make something a pref versus a webextension is a mostly political one, which brings us again to the question: Would you still be proposing to make this a webextension if it also concerned ASCII alphabets that most devs use?

Finally, even if it is true that URLs were not created to be easy to read, the fact remains that there are advantages when they can be easily read, as comments above explained. Putting them in a document or a message is a typical use case. Not only the %-notation quickly becomes prohibitively lengthy, the UTF notation provides a hint as to the content of a URL that can help your reader decide whether s/he wants to open it up or not, and can even help with security on some occasions (e.g., it is much easier to detect a mischievous request or redirect in a URL triggered by a question mark when it is not buried in a long sequence of %CE%A0%01's! )
Sorry, just making clear that when i wrote "the dumbing down of the preferences GUI" i meant the GUI triggered by firofox's pull-down menus (e.g., Edit / Preferences on Linux), not the about:config interface (which barely qualifies as a GUI anyway...)
Actually no extensions required. Please flip the "browser.urlbar.decodeURLsOnCopy" pref.
By the way, Valentin Gosu made this pref. I'm not sure why he did not remember it.

Changing the resolution to clarify the situation.
Resolution: INVALID → DUPLICATE
Duplicate of bug: 1320061
(In reply to Masatoshi Kimura [:emk] from comment #25)
> Actually no extensions required. Please flip the
> "browser.urlbar.decodeURLsOnCopy" pref.
> By the way, Valentin Gosu made this pref. I'm not sure why he did not
> remember it.

Haha. Thanks for the reminder :) This was a long time ago and I forgot it actually landed.
(In reply to Masatoshi Kimura [:emk] from comment #25)
> Actually no extensions required. Please flip the
> "browser.urlbar.decodeURLsOnCopy" pref.

Thanks for the suggestion, Masatoshi. I am using firefox version 52.8.0 and this pref does not seem to exist, is it a newer addition?

If so, am i to understand that network.standard-url.escape-utf8 is now obsolete/deprecated and should be replaced by browser.urlbar.decodeURLsOnCopy ?

That would be awesome, if browser.urlbar.decodeURLsOnCopy has the required functionality --and from the name of it, it sounds like it does! Thanks a lot (and to Valentin as well :) )
(In reply to orionbelt2 from comment #27)
> Thanks for the suggestion, Masatoshi. I am using firefox version 52.8.0 and
> this pref does not seem to exist, is it a newer addition?

It is added since Firefox 53.

> If so, am i to understand that network.standard-url.escape-utf8 is now
> obsolete/deprecated and should be replaced by
> browser.urlbar.decodeURLsOnCopy ?

network.standard-url.escape-utf8 was removed at the same time. Because it had some web-compat issues. browser.urlbar.decodeURLsOnCopy replaced the most demanded use case without the side-effect.
Thanks again for the information. I think i'll stick with the "stable" version of my distribution, which is currently 52.8.0, and i look forward to trying browser.urlbar.decodeURLsOnCopy once they stabilize 53+.
You need to log in before you can comment on or make changes to this bug.