When working with symbols in URL such as greater than (>) or less than (<) they can encoded not in the URL but in what Bubble will return as the paths segment as a list item #
This is what is displayed in the URL address Bar of the browser
Is there a way to automatically translate these back into the character?
As most characters are going to have their own specific encoded key and without needing to test what each gets changed to, is there a simple method to changed the encoded key back to whatever character it was originally?
I gave it a shot but it didnāt translate it back.
Is it a method you have employed before? I feel like it may be an issue I should contact support about because it is the issue is basically the opposite of what Iād expect.
This is the link element that is set up for navigating
And here is what the URL looks like in Browser Address Bar
So it looks like the > symbol is not getting encoded inside of the Browser Address Bar, but the dynamic expressions used to extract a path segment as a list item using a text element, in conditionals and the input element are showing the encoded version.
I would have assumed the Browser Address Bar would have the encoded value while all visual elements, input elements and conditionals would translate it back as is done when using dates or addresses in a URL parameter.
Even more weird is a test I just tried outā¦changing the symbol for the encoded keys in the link, causes the same issue and in fact the normal > symbol is in the Browser Address Bar
I heard back from a Bubble engineer who explained that what I am experiencing is expected behavior.
I just tested using commas and they donāt get encoded in the Browser Address Bar and are returned with a comma so maybe there is some difference in behavior based on the characters
This is the response from Bubble Engineer
The behavior is in fact working-as-intended. The way URLs work is they must always encode special characters (such as ā<ā). Although Iāve noticed that google chrome converts %3E to ā<ā in the URL bar for display purposes, that appears to just be a Chrome quirk; Safari, for instance, still displays it as %3E in the URL bar.
In any case, from the websiteās perspective, they are the same thing, so āGet Page Data from URLā will always return the URL-encoded value, since that is what is in the URL (even if Chrome obfuscates the fact to the end user).
In any case the conditionals recognize the encoded key so maybe it is just a matter of always testing to see the encoded key to use it for conditionals.
I guess I will have to ask the engineer to look at the issue a bit more as this looks different than what my app is producing.
I donāt have edge to test with but using google chrome and firefox I see commas in the browser address bar, but get commas in the text fields, which is different than the < issue that shows the < in the browser address bar but the encoded value in the text fields.
