-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[HOLD for payment 2022-05-20] $500 - Pressing enter/return on request call page is calling onPress function - reported by @Tushu17 #7623
Comments
Triggered auto assignment to @timszot ( |
ProposalWe need to pass App/src/pages/RequestCallPage.js Lines 352 to 356 in 78d6e68
|
Triggered auto assignment to @jboniface ( |
post here |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @rushatgabhane ( |
Triggered auto assignment to @thienlnam ( |
This comment was marked as outdated.
This comment was marked as outdated.
This creates an interesting case here. Pressing enter run an action on the backgrounded Page. This could be a problem in many places. So with regard to the change that @Tushu17 has suggested. I think it would be great if |
@parasharrajat I had the same thinking but the action on backgrounded page isn't run if we go with @Tushu17's proposal. So I'm suggesting that we create a seperate issue for fixing 1.New.Expensify.-.Google.Chrome.2022-02-08.23-48-36.mp4 |
Thanks for bringing this up. I agree that we should fix this because it leads to unexpected behavior like in the video below, and ofc this issue's actual result. Video - The button shouldn't have been pressed for the underlying IOU page. 1.New.Expensify.-.Google.Chrome.2022-02-08.23-51-56.mp4 |
Agreed, a fix should encapsulate the problem here which is that
|
Okay, that works too. @Tushu17 feel free to post an updated proposal which prevents pressOnEnter for backgrounded pages. Thanks! |
waiting for proposals |
ProposalI would suggest a method which uses React SyntheticEvent
|
Since this ( You can just change this App/src/pages/workspace/WorkspaceSettingsPage.js Lines 127 to 135 in 50496a0
to: <Button
success
pressOnEnter
isLoading={this.props.policy.isPolicyUpdating}
isDisabled={!this.props.navigation.isFocused()} // add this
text={this.props.translate('workspace.editor.save')}
onPress={this.submit}
/> Or: <Button
success
isLoading={this.props.policy.isPolicyUpdating}
text={this.props.translate('workspace.editor.save')}
onPress={this.submit}
pressOnEnter={this.props.navigation.isFocused()}
/> If the handling of the Lines 119 to 130 in 50496a0
|
Or maybe it would be best to add the check here: App/src/pages/workspace/WorkspaceSettingsPage.js Lines 92 to 95 in 50496a0
submit() {
if (this.props.policy.isPolicyUpdating || !this.props.navigation.isFocused() || !this.validate()) {
return;
} This way |
Good points overall. But the motive behind doing that change was to cover all pages. This is a generic issue so I thought of handling it everywhere I have another idea. As we changed the keyboard shortcut implementation now, we can just stop the even propagation at the Button handler. Then it will not propagate to other elements. We are running the handler in the capture phase, it won't block other immediate targets from receiving it. All the local event handlers are attached in the bubble phase. |
Ok so it seems it's never desired to have 2 or more buttons with the
I don't understand how that would happen Events are triggered in order of subscription, for this to work they have to be iterated in reverse order |
I think yes. pressOnEnter is meant for CTA. I guess there would be only one per page.
Oh yeah, didn't think of this. I was just seen at an alternative. I guess this will not work. Let me see what else is possible without refactoring too much code. |
I will soon update you here on the status. |
Ok, I tried to think of a solution that works with all the buttons.
<Button
success
isLoading={this.props.policy.isPolicyUpdating}
text={this.props.translate('workspace.editor.save')}
onPress={this.submit}
pressOnEnter={this.props.navigation.isFocused()}
/> approach to applying the solution to all pages. But it will require refactoring of all pages. Not recommended, we still don't know if this will be a problem in the future. Only if there are stacked pages and when the topmost page does not have
cc: @thienlnam |
@parasharrajat Do you think it is a good approach? We might not need to explicitly register a global event listener for We have some more custom form component eg.
|
Hmm, @mdneyazahmad. Seems like too much work for the issue. |
This If it's intended to work on mobile then yes So if this is indeed a web/desktop only behavior the suggestion above would submit only the form that is currently focused: <View accessibilityRole="form" onSubmit={SubmitFunc}>
// here goes form element
</View>
On other apps that I've worked I have a
One thing to note, this is not working on native and it might be intended or not, but it's not clear that /** Call the onPress function when Enter key is pressed */
pressOnEnter: PropTypes.bool, I would not expect that pressing enter/return would submit a form unless I have currently focused a field inside it |
Good points, It could be a extension to our Form component and soon we will refactor all of our forms to use that. |
This will likely work. I like the idea of checking if the current screen is focused before triggering the pressOnEnter. But when/why is the NavigationContext not available?
I also agree we should solve this main issue instead of updating each page so this will be solved |
when we use the button in the components that are out of React navigator. 99% of the pages are used in the navigator except for the Error Page. It has two buttons that crash the app. |
Gotcha, let's go ahead with that solution then @parasharrajat |
Tried one implementation and it has few problems which I am trying to solve. |
Working it now. |
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.1.57-17 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2022-05-20. 🎊 |
@Tushu17 and @parasharrajat the old job post died, let's use this one https://www.upwork.com/jobs/~01b7767e126c5ee6ae |
paid |
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Action Performed:
Expected Result:
Pressing Enter/return should press the Call me button
Actual Result:
Workspace general settings Save button is getting pressed on enter.
Workaround:
unknown
Platform:
Where is this issue occurring?
Version Number: 1.1.37-0
Reproducible in staging?: Y
Reproducible in production?: Y
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: @Tushu17
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1643573796542919
View all open jobs on GitHub
post here
The text was updated successfully, but these errors were encountered: