Open Alexdatadestroyer opened 1 year ago
Updated main post information!
After the report, I decided to run a new test which was made using a [Failure] case on a User Motto and noticed some characters being cut as a side effect of character count discrepancy. Then, I made another test and it happened again.
Message inserted: "RAWeb Github Posts: 13 || Chora ñáö, Canarinha...." Message saved: "RAWeb Github Posts: 13 || Chora ñáö, Canarinha." (This is what gets exhibited on UP later with 3 characters suppressed)
I thought that was only a matter of Javascript case at all. Due to that, I decided to add [Back-end] as a new tag on Issue Title and raised the exception level.
Will be resolved with the move to utf8mb4
later this week.
utf8mb4
is in place and should not be an issue anymore
utf8mb4
is in place and should not be an issue anymore -- luchaos
Sorry, but not true... We are on RAWeb V5.3.0 now, but some older versions were released since when last maintenance took place (03 Nov 2023) - which is when utf8mb4
came to light on Database, if I am not mistaken.
Special characters are still being counted as 2 instead of 1 as shown on first 2 images above (Items a.1 and a.2). This means that if I post the same message without any of these characters with same length, it would be accepted. The only difference between when I made this Bug Report and now is that the Update Button (Set Motto) gets disabled when 50/50 gets is breached. It's not expected to accept more characters after this. However, with special characters, the Text Field still accepts characters and the counter bugs to 50+/50 while showing that in red color and update button remains disabled.
I didn't test any Textarea Element again though (like what is shown on Items b.1 and b.2). It might be fixed there, but it worths a check for sure since this issue has a similar nature to that occurs there on User Motto.
Around 2 months ago, the issue #1619 came to light, then, #1620 came as a solution. However, it produced a minor exception: Since special characters (or diacritics, if you prefer) counts as 2 instead of 1 due to multi-byte char nature, this is causing the counter to mismatch between Characters Inserted VS Character Limit.
Try it! It's fun!
create a BIG TEXT enough to fill 2000 characters of any Textarea element);Screenshots:
a.1) User Motto [Success]: Characters Inserted = Character Limit
a.2) User Motto [Failure]: Characters Inserted > Character Limit. Used 3 special characters as replacement
b.1) Textarea element [Success]: Characters Inserted = Character Limit. Comparison between a character counter website VS RetroAchievements
b.2) Textarea element [Failure]: Characters Inserted > Character Limit. Used 6 special characters as replacement. Comparison between a character counter website VS RetroAchievements showing discrepancy now
Additional Information:
I didn't test, but, since #1677 issue came to light recently, this might happen to exclusive foreign characters like Russian/Ucranian/Bulgarian... ones (Cyrillic Script) and Asiatic ones like Kanji, Romanji too... (This need to be tested in order to assume that we won't have future exceptions regarding this same issue.)
Exception Level: Medium -- This was expected to be a matter of User Interface thing before. However, it affects back-end as some characters would be cut as a side effect of character count discrepancy...