-
Notifications
You must be signed in to change notification settings - Fork 136
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
fix: keep consistency with backend email validation #566
Conversation
Failing to add @aimane-chnaif as reviewer 🤷 |
@jjcoffee please take first round of review and test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Antasel please fix lint. Also, as agreed, we can skip the case of _ prefixed email inside italic markdown. This will make code much simpler.
@aimane-chnaif
Also restored autoemail & quote rule's order and some tweaks on Italic rule |
@aimane-chnaif Can you clarify what you mean by the case of "_ prefixed email inside italic markdown"? Do you mean:
|
__tests__/ExpensiMark-HTML-test.js
Outdated
@@ -102,10 +102,10 @@ test('Test markdown replacement for emails wrapped in bold/strikethrough/italic | |||
expect(parser.replace(testInput)).toBe('<strong><a href="mailto:abc@gmail.com">abc@gmail.com</a></strong>'); | |||
|
|||
testInput = '_abc@gmail.com_'; | |||
expect(parser.replace(testInput)).toBe('<em><a href="mailto:abc@gmail.com">abc@gmail.com</a></em>'); | |||
expect(parser.replace(testInput)).toBe('<a href="mailto:_abc@gmail.com">_abc@gmail.com</a>_'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this would be expected behaviour and would result in a regression. If you wrap a normal email (abc@gmail.com
) in italic markdown it should just be italicised and linked. cc @aimane-chnaif
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. If we just change parsing order of autoEmail and italic, should this be fixed?
@Antasel Let's add all of these in test case. Github markdown seems to have different logic
abc@gmail.com
-> abc@gmail.com_abc@gmail.com
-> _abc@gmail.com__abc@gmail.com
-> __abc@gmail.comabc@gmail.com_
-> abc@gmail.com_abc@gmail.com__
-> abc@gmail.com___abc@gmail.com_
-> abc@gmail.com__abc@gmail.com_
-> _abc@gmail.com_abc@gmail.com__
-> abc@gmail.com___abc@gmail.com__
-> abc@gmail.com
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Antasel Let's add all of these in test case. Github markdown seems to have different logic
abc@gmail.com
-> abc@gmail.com_abc@gmail.com
-> _abc@gmail.com__abc@gmail.com
-> __abc@gmail.comabc@gmail.com_
-> abc@gmail.com_abc@gmail.com__
-> abc@gmail.com___abc@gmail.com_
-> abc@gmail.com__abc@gmail.com_
-> _abc@gmail.com_abc@gmail.com__
-> abc@gmail.com___abc@gmail.com__
-> abc@gmail.com
those cases are already covered in Expensify/App#17387 (comment)
so there is no need to restore the changed order of autoemail and italic rule, just leave it as it is.
I will revert last commit.
How you think ? @jjcoffee
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Antasel Yes I think that's the only way to get the behaviour we want here. I don't think it's possible to isolate a fix for _abc@gmail.com_
from __abc@gmail.com_
, which is what @aimane-chnaif was initially talking about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aimane-chnaif you meant "the case of _ prefixed email inside italic markdown can be skipped" is following case ?
__abc@gmail.com_
-> _abc@gmail.com
after parsed, underscore is not contained in email
if so, it can be done by only moving autoemail rule after italic rule. no need extra tweak in italic rule
cc: @aimane-chnaif
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with it. @jjcoffee you too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Antasel Sorry I'm not clear, what would the result be for __abc@gmail.com_
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That expected to be parsed as _abc@gmail.com but _abc@gmail.com actually, @Antasel you meant correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aimane-chnaif I thought you wanted _<em><a href="mailto:abc@gmail.com">abc@gmail.com</a></em>
after parsed.
currently with Expensify/App#17387 (comment), it is parsed as <em><a href="mailto:_abc@gmail.com">_abc@gmail.com</a></em>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I don't care too much. Either result is fine to me
__tests__/ExpensiMark-HTML-test.js
Outdated
|
||
testInput = '~*_abc@gmail.com_*~'; | ||
expect(parser.replace(testInput)).toBe('<del><strong><em><a href="mailto:abc@gmail.com">abc@gmail.com</a></em></strong></del>'); | ||
expect(parser.replace(testInput)).toBe('<del><strong><a href="mailto:_abc@gmail.com">_abc@gmail.com</a>_</strong></del>'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, I don't think this is the expected behaviour.
@Antasel Let's add some of the markdown tests from |
@Antasel Please can you fix the lint issues again. |
@Antasel I just noticed that your commit signature is unverified. |
thanks, I will do it now, |
The result is not correct for Also doesn't work with it on its own. Can you check @Antasel? |
This is more like a bug in Expensify/App#16762. |
@aimane-chnaif Are you saying it's incorrect to parse |
|
|
@Antasel is it now ready for review? |
we need to check why @jjcoffee is getting incorrectly |
@jjcoffee which platform did you check it on ? |
@Antasel I think all your commits need to be signed - you've only signed the new one. I think that's correct right @aimane-chnaif? I will retest soon - I might have some cached node_modules messing things up 😄 |
@Antasel there's still unsigned commit. All commits should be signed |
@Antasel It fails when I add it as a test, so it must be an issue with the regex: |
This was reported before and now marked as fixed - Expensify/App#21266 |
@Antasel Can you try merging main in case the issue is resolved by the PR @aimane-chnaif mentions? |
noted, let me try |
@jjcoffee |
yes, sure |
@jjcoffee @aimane-chnaif |
@aimane-chnaif @jjcoffee |
@Antasel Agree it looks like a separate issue. From what I understand, any invalid email (like a super long email that's over the length limits) will not be parsed by the email rule so the autolinker tries to parse it and fails because of issues with the autolink rule. I think it's worth reporting this as a separate bug on Slack. I think next steps here are to add some additional manual tests:
I will run some platform tests today, but otherwise it's ready for review. We're running close to the 9 day limit for merging, so let's try and get this merged today! cc @aimane-chnaif |
@jjcoffee noted |
@Antasel Actually we can ignore tests for sign-in as if FE validates, BE will still return that it's an invalid email (the error message is just slightly different). Also, there's now(?) a length limit on all email input fields, so you can't enter an email >254 chars anyway 😄 Can you add |
I've added it and updated demo video. |
@Antasel Thanks! Please also remove the |
Tests well, just waiting for the Android build. I think this is ready for review @aimane-chnaif - please prioritise as we're getting close to the 9 day limit. Thanks! Screenshots/VideosWebNew Contact method email-regex-chrome-desktop-contact-method-2023-08-24_15.32.58.mp4Markdown email-regex-chrome-desktop-markdown-2023-08-24_15.34.03.mp4Mobile Web - ChromeNew Contact method android-chrome-contact-methods.mp4Markdown - valid android-chrome-markdown.mp4Markdown - invalid Uploading android-chrome-markdown-invalid.mp4… Mobile Web - Safariemail-regex-ios-safari-2023-08-24_17.08.50.mp4Desktopemail-regex-mac-desktop-2023-08-24_17.15.02.mp4iOSNew Contact method email-regex-ios-native-contact-method-2023-08-24_17.26.22.mp4Markdown email-regex-ios-native-markdown-2023-08-24_16.55.48.mp4Androidemail-regex-android-2023-08-25_14.35.53.mp4 |
It's removed |
Android test added! @aimane-chnaif Do you think you can review today? |
I guess this is to do with putting the |
@aimane-chnaif Actually this is current behaviour on main, so unrelated to this PR: |
Screenshots/VideosWebvalid.emails.movinvalid.emails.movcontact.method.movMobile Web - Chromemchrome.movMobile Web - Safarimsafari.movDesktopdesktop.moviOSios.movAndroidandroid.mov |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@NikkiWines all yours
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing 🤩 one very minor question but otherwise looks good.
__tests__/Str-test.js
Outdated
expect(Str.isValidEmail('test@gmail')).toBeFalsy(); | ||
expect(Str.isValidEmail('@gmail.com')).toBeFalsy(); | ||
expect(Str.isValidEmail('usernamelongerthan64charactersshouldnotworkaccordingtorfc822whichisusedbyphp@gmail.com')).toBeFalsy(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of these should still be invalid, right? Why not retain these tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though looks like at least the last one is already covered by the test on 184
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@NikkiWines @aimane-chnaif
The cases have been restored.
{ | ||
/** | ||
* Use \b in this case because it will match on words, letters, | ||
* and _: https://www.rexegg.com/regex-boundaries.html#wordboundary | ||
* The !_blank is to prevent the `target="_blank">` section of the | ||
* link replacement from being captured Additionally, something like | ||
* `\b\_([^<>]*?)\_\b` doesn't work because it won't replace | ||
* `_https://www.test.com_` | ||
* Use [\s\S]* instead of .* to match newline | ||
*/ | ||
name: 'italic', | ||
regex: /(\b_+|\b)(?!_blank")_((?![\s_])[\s\S]*?[^\s_])_(?![^\W_])(?![^<]*(<\/pre>|<\/code>|<\/a>|<\/mention-user>|_blank))/g, | ||
|
||
// We want to add extraLeadingUnderscores back before the <em> tag unless textWithinUnderscores starts with valid email | ||
replacement: (match, extraLeadingUnderscores, textWithinUnderscores) => { | ||
if (textWithinUnderscores.includes('<pre>') || this.containsNonPairTag(textWithinUnderscores)) { | ||
return match; | ||
} | ||
if (String(textWithinUnderscores).match(`^${CONST.REG_EXP.MARKDOWN_EMAIL}`)) { | ||
return `<em>${extraLeadingUnderscores}${textWithinUnderscores}</em>`; | ||
} | ||
return `${extraLeadingUnderscores}<em>${textWithinUnderscores}</em>`; | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We used to have the quote rule run before the italic rule. Changing that order caused an invalid markdown rendering for cases like:
_Msg then a
> quote_
Coming from Expensify/App#26941
Fixed Issues
$ Expensify/App#17387
Proposal: Expensify/App#17387 (comment), Expensify/App#17387 (comment)
Tests
Valid emails
Invalid emails
Demo Video:
test-keep-consistency-with-email-validation.mp4
Autotest cases:
Str-test.js new tests
ExpensiMark-HTML-test.js new tests