Roll20 Chat using [Text](URL) breaks when URL contains Parenthesis

I recently was building a Spell Macro to streamline Spellcards using Chat Menus API Trick (from Roll20 Tips and Tricks (Innovative Solutions to Common Problems) Thread), and one of the URLs I attempted to reference specifically included Parenthesis: this immediately broke the URL Link; and Roll20 apparently doesn't HTML Parser the URL before constructing the resulting URL despite it getting submitted to Chat using ( and ) thus, meaning; the "(" & ")" cannot get bypassed, and there is no URL parser equivalent comparable to “Space” (%20) , (Edit: %28 and %29 had to be added to the Destination's URL Resolution Parser using a URI Exception). I asked a few (nameless) 3rd-Party Web Developers what they knew on this subject, and upon multiple Discord Pages probing the topic, it was revealed that this specifically is a Roll20 problem, specifically; a Roll20 Markdown Parser problem combined with a Roll20 Order Of Operations Problem, as HTML Parser should kick in BEFORE the URL Parser, NOT after, though these should both kick in AFTER the Markdown Parser. Specifically: I was attempting to link to a (UA) Spell, and " (ua) " was specifically included in the URL. To clarify: ( and ) appear in the URL, they should be ( and ) in the URL.

Have you tried using %28 and %29 they are the URL-encoded versions of "(" and ")"  ?

I addressed this problem on their end, but the encoding order of operations still is wrong; and it's URI Encoded versions.

I'm curious to see what the macro originally looked like since I'm having trouble recreating the problem.

The URL encoded versions seem to work fine for me - %28 and %29. You can also just use tinyURL or something similar to generate your own link, if encoding doesn't work. Having raw control characters in a URL is pretty uncommon, I'm not sure this is really a Roll20 problem to be solved... what's the URL you're struggling with? I'm not sure what you mean about the order of operations, either - that's the way it needs to happen. Markdown parser => turn [label](link) into <a> tag HTML => render <a> element => user clicks <a> element => browser decodes URI string and navigates to page How could that work in a different order?

Oosh said: The URL encoded versions seem to work fine for me - %28 and %29. You can also just use tinyURL or something similar to generate your own link, if encoding doesn't work. Having raw control characters in a URL is pretty uncommon, I'm not sure this is really a Roll20 problem to be solved... what's the URL you're struggling with? I'm not sure what you mean about the order of operations, either - that's the way it needs to happen. Markdown parser => turn [label](link) into <a> tag HTML => render <a> element => user clicks <a> element => browser decodes URI string and navigates to page How could that work in a different order? Blue64 said: ... HTML Parser should kick in BEFORE the URL Parser, NOT after, though these should both kick in AFTER the Markdown Parser. Specifically: I was attempting to link to a (UA) Spell, and "(ua)" was specifically included in the URL. To clarify: ( and ) appear in the URL, they should be ( and ) in the URL. What do you not understand? Markdown Parser: Define URL Boundary: [Text](URL(UA)) HTML Parser: turn ( into ( HTML Parser: turn ) into ) URL Parser makes [Text](URL(UA)) Clickable without turning into [Text](URL(UA) +) or [Text](URL(UA) Your Markdown Parser instead currently operates like this: Markdown Parser: Define URL Boundary: [Text](URL(UA)) URL Parser: makes [Text](URL ( UA ) ) Clickable Now this is a Value, not a Variable This cannot get changed further HTML Parser: turn ( into ( HTML Parser: turn ) into ) And the fact that the Destination already added this URI Encoded Exception to their URL Resolution Parser is irrelevant from the fact that I can perform HTML Parser Buffer on everything except a URL. You can now easily see why changing the Order of Operations was requested; I can make clickable buttons for nearly any other feature, and those get HTML Parser, though a [Text](URL) doesn't HTML Parser, at all.

@Blue64, could you share an example url for us so we can play with it and see if there is in fact a workaround or not? Thanks in advance!