[HOLD for payment 2024-12-09] [$250] Web/Safari - Account -The email field error appears after successfully signing in with an Apple account
If you havenβt already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: v9.0.65-1 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: Issue reported by: Applause Internal Team
Action Performed:
- Go to the sign-in page (log out if you're already logged in)
- Click on the Apple button
- Enter or select a Apple Account
Expected Result:
The user is logged correctly into NewDot, no errors are displayed,
Actual Result:
The email field error appears after successfully signing in with an Apple account
Workaround:
Unknown
Platforms:
- [ ] Android: Standalone
- [ ] Android: HybridApp
- [ ] Android: mWeb Chrome
- [ ] iOS: Standalone
- [ ] iOS: HybridApp
- [ ] iOS: mWeb Safari
- [x] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
https://github.com/user-attachments/assets/2086417a-a44a-4068-98d2-c50c6a18d968
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021859629436988834132
- Upwork Job ID: 1859629436988834132
- Last Price Increase: 2024-11-21
- Automatic offers:
- huult | Contributor | 105055065
- CyberAndrii | Contributor | 105062061
Issue Owner
Current Issue Owner: @sakluger
Triggered auto assignment to @sakluger (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
Job added to Upwork: https://www.upwork.com/jobs/~021859629436988834132
Triggered auto assignment to Contributor-plus team member for initial proposal review - @akinwale (External)
Edited by proposal-police: This proposal was edited at 2024-11-21 18:05:48 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
The email field error appears after successfully signing in with an Apple account
What is the root cause of that problem?
When we click the Apple icon, a popup appears that prevents the onBlur of the TextInput from being executed. When we return to the Expensify app, the onBlur is executed and validates with the login value as ''.
https://github.com/Expensify/App/blob/b4a8a41f46468a2f336070054f4036d9c04f94a7/src/pages/signin/LoginForm/BaseLoginForm.tsx#L245-L252
https://github.com/user-attachments/assets/53b86695-1933-425b-abe3-e28c70bbf100
The reason validate(login); is executed is that isSigningWithAppleOrGoogle.current is not updated to true for desktop web, so the early return is not triggered.
isSigningWithAppleOrGoogle.current is not updated to true because we did not add the onPress handler for the desktop web version
https://github.com/Expensify/App/blob/f84785d53768a155bad3398ebb46d48c3f9eaf57/src/components/SignInButtons/AppleSignIn/index.tsx#L139
What changes do you think we should make in order to solve the problem?
To resolve this issue, we must call onPress when AppleSignIn is clicked so that isSigningWithAppleOrGoogle.current can be updated. This allows the onBlur to return early without calling validate(login);. Something like this:
We pass the onPress prop from BaseLoginForm to AppleSignInDiv and add an event listener for the click to call onPress
// src/components/SignInButtons/AppleSignIn/index.tsx#L83
React.useEffect(() => {
const appleSignInButton = document.getElementById('appleid-signin');
if (!appleSignInButton && !isDesktopFlow) {
return;
}
appleSignInButton?.addEventListener('click', () => {
onPress?.();
});
return () => {
appleSignInButton?.removeEventListener('click', () => {
onPress?.();
});
};
});
note: If Google Sign-In has the same issue, we can reuse this solution
Test branch
POC
https://github.com/user-attachments/assets/430cf29b-fe16-4685-8db6-001e0806588b
What alternative solutions did you explore? (Optional)
Proposal
Please re-state the problem that we are trying to solve in this issue.
The email field error appears when clicking on the "Sign in with Apple/Google" buttons
What is the root cause of that problem?
On the login page we skip the validate(login) call if isSigningWithAppleOrGoogle.current is set to true.
https://github.com/Expensify/App/blob/2b312769d1bb8b621b30a11be26fddcbd4b9c738/src/pages/signin/LoginForm/BaseLoginForm.tsx#L246-L251
isSigningWithAppleOrGoogle is set here when the sign in button is clicked
https://github.com/Expensify/App/blob/2b312769d1bb8b621b30a11be26fddcbd4b9c738/src/pages/signin/LoginForm/BaseLoginForm.tsx#L307-L312
The issue occurs because neither AppleSignIn nor GoogleSignIn components invoke the onPress callback passed to them.
What changes do you think we should make in order to solve the problem?
We need to invoke the callback by passing it to onPointerDown (which is the div's alternative to onPress).
Important: Unlike onClick, which is triggered after the mouse-up event, onPointerDown is fired immediately when the button is pressed. Using onClick would cause the error to remain visible until the mouse is released.
AppleSignIn:
return isDesktopFlow ? (
<div
id="appleid-signin"
...
+ onPointerDown={onPress}
/>
) : (
<div
id="appleid-signin"
...
+ onPointerDown={onPress}
/>
);
GoogleSignIn:
return isDesktopFlow ? (
<View style={styles.googlePillButtonContainer}>
<div
id={desktopId}
...
+ onPointerDown={onPress}
/>
</View>
) : (
<View style={[styles.googleButtonContainer, styles.willChangeTransform]}>
<div
id={mainId}
...
+ onPointerDown={onPress}
/>
</View>
);
See all changes on my test branch: https://github.com/Expensify/App/compare/main...CyberAndrii:ExpensifyApp:52882-fix-error-when-clicking-on-Sign-In-with-Apple-or-Google
@huult's proposal works here.
@huult Additionally, please test and verify if the same issue exists for Google sign in so that that can be addressed as well in your PR. Thanks.
πππ C+ reviewed.
Triggered auto assignment to @mjasikowski, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@akinwale hey, did you review my proposal? It explains why @huult's solution won't fully fix the issue.
Unlike onClick, which is triggered after the mouse-up event, onPointerDown is fired immediately when the button is pressed. Using onClick would cause the error to remain visible until the mouse is released.
(when pressing on the button like this)
https://github.com/user-attachments/assets/7bd95eb7-2c8c-4b49-84e5-50e5622b0869
Note for C+ @akinwale , When we hold the mouse and move it out, as @CyberAndrii mentioned, it still shows the error field when we click elsewhere. This is not related to this ticket.
https://github.com/user-attachments/assets/44098ddd-a161-47ab-8d93-587f2ddf04f6
Thank you for your review, @akinwale . I appreciate your time, @mjasikowski , and will wait for your assignment. Thank you!
When we hold the mouse and move it out, as @CyberAndrii mentioned, it still shows the error field when we click elsewhere. This is not related to this ticket.
To clarify, the mouse doesn't need to be moved out or clicked elsewhere. After the mouse button is released, it will continue with the sign in flow. With huut's proposal the error will be hidden only when the mouse is released. With my proposal the error won't appear at all.
Let's go with @huult's proposal - it was submitted earlier @CyberAndrii's solution is largely the same, albeit using a different event. Please check if @CyberAndrii's assumption about onPointerDown vs onClick. If that's correct, please use onPointerDown instead.
Any Apple/Google Sign-in errors related to incorrect mouse event handling should be treated as in scope of this issue.
@sakluger let's pay $50 to @CyberAndrii for a valuable addition to the selected proposal.
π£ @huult π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
Thank you! I will create the pull request within 24 hours
Sounds good @mjasikowski! I'm going to assign @CyberAndrii to the GH issue so that it auto-creates an Upwork contract.
π£ @CyberAndrii π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
Reviewing label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.69-4 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
- https://github.com/Expensify/App/pull/53109
If no regressions arise, payment will be issued on 2024-12-09. :confetti_ball:
For reference, here are some details about the assignees on this issue:
- @akinwale requires payment through NewDot Manual Requests
- @huult requires payment automatic offer (Contributor)
- @CyberAndrii requires payment automatic offer (Contributor)
@akinwale @sakluger @akinwale The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
BugZero Checklist:
- [x] [Contributor] Classify the bug:
Bug classification
Source of bug:
- [x] 1a. Result of the original design (eg. a case wasn't considered)
- [ ] 1b. Mistake during implementation
- [ ] 1c. Backend bug
- [ ] 1z. Other:
Where bug was reported:
- [x] 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
- [ ] 2b. Reported on staging (eg. found during regression or PR testing)
- [ ] 2d. Reported on a PR
- [ ] 2z. Other:
Who reported the bug:
- [ ] 3a. Expensify user
- [ ] 3b. Expensify employee
- [ ] 3c. Contributor
- [x] 3d. QA
- [ ] 3z. Other:
-
[x] [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to comment: N/A
-
[x] [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: N/A
-
[x] [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
-
[x] [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Test:
- Launch the Expensify app
- Sign out if you are already signed in
- Click on the Apple sign-in button
- Enter the required Apple account credentials or select an existing Apple account, if any
- Verify that after the user is successfully signed in, no error is displayed below the Phone or email input field on the sign in screen
- Repeat the test from step 3 using the Google sign-in button
Do we agree π or π?
Looks good, thanks!
Summarizing payment on this issue:
Contributor: @CyberAndrii $50, paid via Upwork Contributor: @huult $250, paid via Upwork Contributor+: @akinwale $250, please request on Newdot
$250 approved for @akinwale