The regex used in ChatClickData doesn't match on valid URLs which use an IP4 address, port, hash (#), or have comma in the query string. This makes a large variety of valid URLs "un-clickable" in the Chat GUI.
ChatClickData
Pattern pattern = Pattern.compile("^(?:(https?)://)?([-\\w_\\.]{2,}\\.[a-z]{2,4})(/\\S*)?$");
As a fix, the proposed regex will accept either TLD or IP4, optionally allows port, and accepts a hash or commas in the query string:
ChatClickData
Pattern pattern = Pattern.compile("^(https?:\\/\\/)?"+ // protocol
"((([a-z\\d]([a-z\\d-]*[a-z\\d])*)\\.)+[a-z]{2,}|"+ // domain name
"((\\d{1,3}\\.){3}\\d{1,3}))"+ // OR ip (v4) address
"(\\:\\d+)?(\\/[-a-z\\d%_.~+]*)*"+ // port and path
"(\\?[;&a-z\\d%_.~+=-]*)?"+ // query string
"(\\#[-a-z\\d_]*)?$"); // hash
Here's a JSFiddle showing the current and proposed regexes in action:
http://jsfiddle.net/mwoodman/UycV9/
Note that the current regex is failing to match on more than half of the URLs tested (2766 out of 4704). The proposed regex passes all of the URLs tested.
Linked issues
Comments 8
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. If this has been done, we can reopen the issue.
Keep in mind that the "Resolved"-Status on this ticket just means "Answered", and that we are waiting for further information on whether this issue still exists or not. We will reopen it as soon as the requested information has been deliviered.
Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time.
Invalid, clicking links in chat is a removed feature, see MC-30864
@@unknown That's referring to parsing user input for links in chat. This ticket is still valid in that regard since you can use the open_url
click event for the text component (which is used for both chat and books). However, this appears to no longer be an issue as links now use Java's URI class (while restricting the scheme to "http" or "https").
Definitely something I've experienced and would love to see the suggested implementation in place, much more dynamic and flexible.