In the source code for Firefox 52 ESR I see this:

// Whether URL,Location,Link::GetHash should be percent encoded // in setter and percent decoded in getter (old behaviour = true) pref("dom.url.encode_decode_hash", true);

That is no longer present in Firefox 57.

What effect did that preference have??

Use This pref instead:

• browser.urlbar.decodeURLsOnCopy
• https://dxr.mozilla.org/mozilla-release/source/browser/app/profile/firefox.js#341
• https://dxr.mozilla.org/mozilla-release/source/browser/base/content/urlbarBindings.xml

• Bug 1320061 - Copying non-ascii URI from location bar

(please do not comment in bug reports
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html)

Thanks for both reply. What I have seen is, we have a CN/JP group at when the user click on line, the URL show as https://<ip>/#/user/show/r/rest/logindomains/grouptorolemapping/3/測試 and on the same page (detail panel). It suppose to show the detail of that group information. (Prior to version 57), the page cannot be displayed and but once we change the dom.url.encode_decode_hash to false. It display correctly.

(Version 57 and latest) since we cannot find that setting, we don't know to make that page display. On Version 57, I change browser.urlbar.decodeURLsOnCopy to false, it doesn't help.

Thanks, Mav

It looks as though Firefox 57 no longer checks that preference and behaves as though it is "true".

Compare

https://dxr.mozilla.org/mozilla-release/source/netwerk/base/nsStandardURL.cpp#847

with

https://dxr.mozilla.org/mozilla-esr52/source/netwerk/base/nsStandardURL.cpp#714

jscher2000 said

It looks as though Firefox 57 no longer checks that preference and behaves as though it is "true". Compare https://dxr.mozilla.org/mozilla-release/source/netwerk/base/nsStandardURL.cpp#847 with https://dxr.mozilla.org/mozilla-esr52/source/netwerk/base/nsStandardURL.cpp#714

Is that a new feature/bug? Will that be enhance in the future?

mluvw47 said

Is that a new feature/bug? Will that be enhance in the future?

This was changed in Firefox 55. There is a note in the changeset:

These prefs have been added close to two years ago: dom.url.encode_decode_hash and dom.url.getters_decode_hash The main reason for their existence was in case we encounter any web-compat issues. At this point the extra code is mostly useless, and flipping the pref may lead to crashes.

So it seems to be a permanent change.

I don't understand the problem you're encountering with your app:

mluvw47 said

What I have seen is, we have a CN/JP group at when the user click on line, the URL show as https://<ip>/#/user/show/r/rest/logindomains/grouptorolemapping/3/測試 and on the same page (detail panel). It suppose to show the detail of that group information.
(Prior to version 57), the page cannot be displayed and but once we change the dom.url.encode_decode_hash to false. It display correctly.
(Version 57 and latest) since we cannot find that setting, we don't know to make that page display.

If you can't use the hash with URL-encoded Chinese characters --

"#/user/show/r/rest/logindomains/grouptorolemapping/3/%E6%B8%AC%E8%A9%A6"

-- you need to do something like this in your script --

decodeURIComponent(location.hash)

-- to get:

"#/user/show/r/rest/logindomains/grouptorolemapping/3/測試"

jscher2000 said

mluvw47 said

Is that a new feature/bug? Will that be enhance in the future?

This was changed in Firefox 55. There is a note in the changeset:

These prefs have been added close to two years ago: dom.url.encode_decode_hash and dom.url.getters_decode_hash The main reason for their existence was in case we encounter any web-compat issues. At this point the extra code is mostly useless, and flipping the pref may lead to crashes.

So it seems to be a permanent change.

I don't understand the problem you're encountering with your app:

mluvw47 said

What I have seen is, we have a CN/JP group at when the user click on line, the URL show as https://<ip>/#/user/show/r/rest/logindomains/grouptorolemapping/3/測試 and on the same page (detail panel). It suppose to show the detail of that group information.
(Prior to version 57), the page cannot be displayed and but once we change the dom.url.encode_decode_hash to false. It display correctly.
(Version 57 and latest) since we cannot find that setting, we don't know to make that page display.

If you can't use the hash with URL-encoded Chinese characters --

"#/user/show/r/rest/logindomains/grouptorolemapping/3/%E6%B8%AC%E8%A9%A6"

-- you need to do something like this in your script --

decodeURIComponent(location.hash)

-- to get:

"#/user/show/r/rest/logindomains/grouptorolemapping/3/測試"

But I don't quite understand, the link already has been shown as "#/user/show/r/rest/logindomains/grouptorolemapping/3/測試" at the first place in both firefox 52 or the latest version. Does it mean that is already been decode correctly?

The URL bar shows unicode (Chinese characters) in both versions. No problem there.

I thought the issue was that a script in your page needs to read the hash to modify the display, for example, to retrieve additional content from the server or show/hide particular parts of a page. Apparently, that depends on decoding or not decoding the hash; it's hard to know. That was my best guess. But I don't really know what is happening on a page I can't see (or even, many times, on a page I can see), so that is just a guess.

REST in a link usually means that you query an API to get a JSON response, so maybe the API can't handle both formats if it no longer works?