X
Tap here to go to the mobile version of the site.

Support Forum

dom.url.getters_decode_hash preference is missing.

Posted

I use Secret Server by thycotic. There is a known issue where the site does not display properly and this is fixed by setting the preference "dom.url.getters_decode_hash" to true. They have a public article describing this (https://thycotic.force.com/support/s/article/ka0370000005PuPAAU/Blank-Dashboard-in-Firefox).

When I set this preference previously it fixed the issue however lately I noticed that it doesn't appear to be working anymore even though it is still set properly. I uninstalled and reinstalled Firefox and "refreshed", and when I went back into the about:config page the preference was nowhere to be seen. Sooo, I tried creating it manually - no effect...

Has this preference been removed? Is there a replacement which will fix this issue?

I use Secret Server by thycotic. There is a known issue where the site does not display properly and this is fixed by setting the preference "dom.url.getters_decode_hash" to true. They have a public article describing this (https://thycotic.force.com/support/s/article/ka0370000005PuPAAU/Blank-Dashboard-in-Firefox). When I set this preference previously it fixed the issue however lately I noticed that it doesn't appear to be working anymore even though it is still set properly. I uninstalled and reinstalled Firefox and "refreshed", and when I went back into the about:config page the preference was nowhere to be seen. Sooo, I tried creating it manually - no effect... Has this preference been removed? Is there a replacement which will fix this issue?
Quote

Additional System Details

Installed Plug-ins

  • Shockwave Flash 27.0 r0

Application

  • User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

More Information

cor-el
  • Top 10 Contributor
  • Moderator
15462 solutions 140030 answers

Yes. The url hash prefs have been removed.

dom.url.getters_decode_hash dom.url.encode_decode_hash

See also browser.urlbar.decodeURLsOnCopy


bug 1342438 - Remove url .hash encoding/decoding prefs

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

Yes. The url hash prefs have been removed. dom.url.getters_decode_hash dom.url.encode_decode_hash See also browser.urlbar.decodeURLsOnCopy ---- [https://bugzilla.mozilla.org/show_bug.cgi?id=1342438 bug 1342438] - Remove url .hash encoding/decoding prefs (<i>please do not comment in bug reports<br>https://bugzilla.mozilla.org/page.cgi?id=etiquette.html</i>)

Modified by cor-el

Was this helpful to you?
Quote

Question owner

Thanks. So I assume there's no other way to workaround this issue? Sites have to change their design...

Thanks. So I assume there's no other way to workaround this issue? Sites have to change their design...
Was this helpful to you?
Quote
cor-el
  • Top 10 Contributor
  • Moderator
15462 solutions 140030 answers

You would first have to describe why you need the feature that these prefs previously controlled. What appears on the location/address bar that you need to change or it this happening when you use the right-click context menu to copy a link?

You would first have to describe why you need the feature that these prefs previously controlled. What appears on the location/address bar that you need to change or it this happening when you use the right-click context menu to copy a link?
Was this helpful to you?
Quote

Question owner

This is an example of what the URL looks like:

https://<site>/ss/dashboard.aspx#{%27tId%27:153}

When viewing this site without that preference set to true, the site doesn't display any of its content. Without a full understanding of the technical issue I'm assuming that the hash would be causing this issue and previously that preference would work around it.

This isn't my site, it's a 3rd party product that we use at my place of work as I described in my initial post. To me it seems that this is a compatibility or design issue on their part. At the same time other browsers display this product without issue. So, for me, it means that I have to use a different browser to access this particular site which is an inconvenience. That said, as this is "their" product it should be incumbent upon them to fix this if it is what would be considered to be poor design, so I'm not really interested in spending a lot of time with this issue. I was more interested to know know if there was an alternate workaround.

Thanks again.

This is an example of what the URL looks like: https://<site>/ss/dashboard.aspx#{%27tId%27:153} When viewing this site without that preference set to true, the site doesn't display any of its content. Without a full understanding of the technical issue I'm assuming that the hash would be causing this issue and previously that preference would work around it. This isn't my site, it's a 3rd party product that we use at my place of work as I described in my initial post. To me it seems that this is a compatibility or design issue on their part. At the same time other browsers display this product without issue. So, for me, it means that I have to use a different browser to access this particular site which is an inconvenience. That said, as this is "their" product it should be incumbent upon them to fix this if it is what would be considered to be poor design, so I'm not really interested in spending a lot of time with this issue. I was more interested to know know if there was an alternate workaround. Thanks again.
Was this helpful to you?
Quote
Ask a question

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.