Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(web): TransformUtils.insertWhitespace seems convoluted #7232

Closed
mcdurdin opened this issue Sep 8, 2022 · 4 comments · Fixed by #7241
Closed

chore(web): TransformUtils.insertWhitespace seems convoluted #7232

mcdurdin opened this issue Sep 8, 2022 · 4 comments · Fixed by #7241
Milestone

Comments

@mcdurdin
Copy link
Member

mcdurdin commented Sep 8, 2022

This seems a little convoluted.

  • I'm really not sure exactly what we are testing here. It seems like you are looking for insert.match(/[\u0009...]$/)? Is it intended to match having a single whitespace character on the end of the text? If so, then the function name is not very clear. If not, then AFAICT the function is not correct.

  • i modifier should not be necessary on the regex -- there's no case to be insensitive about 🤣.

  • Can we use a character class for the regex match rather than a set of characters? (e.g. insert.match(/[\p{Z}\r\n]$/u). Note Chrome 50+ though (so we could have the shorter regex as a comment if we can't use it for back-compat reasons).

  • Finally, can we have a javadoc comment rather than the in-function comment?

Originally posted by @mcdurdin in #7205 (comment)

@mcdurdin
Copy link
Member Author

mcdurdin commented Sep 8, 2022

JH wrote:

Keep in mind that I did not edit this function at all. I simply extracted it from its prior home. From master:

protected isWhitespace(transform: Transform): boolean {
// Matches prefixed text + any instance of a character with Unicode general property Z* or the following: CR, LF, and Tab.
let whitespaceRemover = /.*[\u0009\u000A\u000D\u0020\u00a0\u1680\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u200b\u2028\u2029\u202f\u205f\u3000]/i;
// Filter out null-inserts; their high probability can cause issues.
if(transform.insert == '') { // Can actually register as 'whitespace'.
return false;
}
let insert = transform.insert;
insert = insert.replace(whitespaceRemover, '');
return insert == '';
}

This all dates back to #1851, and @eddieantonio was the one responsible for that regex: #1851 (comment)

Can't speak to why he didn't use a character class here, but I figure that there was some reason or other. For what it's worth, following that character class link and drilling down to the actual classes: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Character_Classes

I don't see a compatibility chart there. Now, there are other ways to search for this...

https://caniuse.com/mdn-javascript_builtins_regexp_property_escapes

Note the minimum Chrome version listed there - if desktop Chrome didn't support these property escapes before version 64, I doubt that mobile had it implemented at that time. This, to me, implies a strong chance that using them would break predictive text outright on non-updated Android 5.0 devices, at the least.


Where do you see a $ in the regex string here? Is it implied with the flags on the pattern? It's certainly not present in plain-text.

@mcdurdin mcdurdin added this to the Future milestone Sep 8, 2022
@jahorton jahorton modified the milestones: Future, A16S10 Sep 16, 2022
@jahorton
Copy link
Contributor

Well... we ended up going ahead and addressing it ahead of time anyway. Took a few iterations to settle on the solution, though.

@mcdurdin
Copy link
Member Author

Well... we ended up going ahead and addressing it ahead of time anyway.

Can you link the PR that addressed this?

@jahorton
Copy link
Contributor

Addressed by #7241.

@jahorton jahorton linked a pull request Sep 19, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants