It's been a month, and I'm sure this issue
has (technically) been solved (
EDIT: back in Chrome 59 and I'm wrong). Nonetheless, I feel like explaining the issue here.
After doing a little research, this seems to have been an issue with Chrome 57+
that was resolved with Chrome 58 (hence the issue is now technically solved). This explains why OP wasn't having issues when using Chromium versus Chrome: it was a different version that either didn't have a flawed XSS auditor, or had a fixed XSS auditor.
"What's this 'XSS auditor' thing?"
Simply, the XSS auditor is a function in Chromium (and therefore Chrome) that attempts to identify malicious code (specifically, certain forms of
XSS) being sent in the parameters of HTTP requests and blocks responses where it thinks the malicious code was injected into the server's response. More specifically, if your browser submits a form with a malicious script and the server responds with a page that contains that same malicious script, the XSS auditor rejects the server's response as it assumes that the code that was "injected" is malicious and could be harmful to the user.
This happens when you hit the "More Options..." button because that button submits what you have written (which is HTML when using the Rich Text Editor) so it can be shown again on the page that shows more options.
-----
I decided I should also identify specifically what Chrome was misidentifying as malicious. I couldn't get any of my posts (I actually only tried ATCF lol) to trigger it after downloading Chrome 57, so I quoted CC 59 and hit the "More Options..." and that successfully triggered the error.
From there, I started taking out parts of the post. I took out the user content as that seems to change between posts and would therefore not cause an issue with
all CC posts--and I was right. Then I started taking out parts of the start of each CC (which is the same) until the error didn't happen.
I narrowed the error down to this paragraph:
I was confused at first.
What's odd about that paragraph? The only special bit about it is the link, but other parts of the CC intro have links and don't cause the issue. So I narrowed down further, and found the single issue (in this case) that caused the auditor to block the response:
The link in the quote above points to a part of the forum using a url with HTTPS.
Specifically, any BB Code URL that points to 'http
s://forums.terraria.org/' and any path following it would cause the XSS auditor to incorrectly block responses.
Why? I dunno. Somebody at Google messed up.
-----
I'm going to put my own personal opinion and say there's no need for the forum staff (specifically the lovely Skiphs) to do anything about this. The lengths they have to go in order to fix this bug with an
older version of Chromium (even more,
not the forum) is not worth it.
I even found a fair
workaround in Chrome 57: toggle into the BB code editor (the button in the upper-right)
and then hit "More Options...". You'll land on the page you want in the rich text editor, as you'd like. The reason this works is because XenForo submits BB code when you're in the BB code editor, and the XSS auditor doesn't look for BB code as a form of XSS, and therefore doesn't consider the HTTP request's paramters to be malicious.
I'm also going to say that this should, by far,
NOT cause people to make forum links point to HTTP instead of HTTPS. As a general guideline, I reccommend that all links to the forum
should point to the HTTPS protocol for the forum's URL.
-----
Oops, went off topic, back to working on ATCF 2
