Closed kbecciv closed 12 months ago
resetFullComposerSize
- which will set the isFullComposerAvailable
state to false
regardless the isSendDisabled
is true or not. That leads to the bug: When the composer has > 15.000 characters, clicking on <SendButton />
will make the expand button disappear. This is the RCA that directly lead to this bug.isSendDisable
is false
still triggers a few functions: For example:
https://github.com/Expensify/App/blob/436b75dbd6498c3d76a90efbe542ee7b2fcbc20c/src/pages/home/report/ReportActionCompose/SendButton.js#L36-L49<SendButton />
not only trigger submitForm
, but also setIsCommentEmpty
, resetFullComposerSize
and updatePropsPaperWorklet
So we should create a function that handles both clicking send button and pressing ENTER, like below:
const handleClickingOnSendOrPressingEnter = (isSendDisable) => {
if (isSendDisable) {
return;
} else {
'worklet';
const viewTag = animatedRef();
const viewName = 'RCTMultilineTextInputView';
const updates = {text: ''};
// We are setting the isCommentEmpty flag to true so the status of it will be in sync of the native text input state
runOnJS(setIsCommentEmpty)(true);
runOnJS(resetFullComposerSize)();
updatePropsPaperWorklet(viewTag, viewName, updates); // clears native text input on the UI thread
runOnJS(submitForm)();
}
};
isSendDisable
is true, stop the function so that the bug is fixed and the logic when clicking SendButton or pressing ENTER is clearerIf you could update your proposal so that send button won't be disabled during chat loading, but be disabled only after clicking on it
<ReportFooter {... currentProps} isReportReadyForDisplay={isReportReadyForDisplay} />
handleClickingOnSendOrPressingEnter
in my proposal to:
const handleClickingOnSendOrPressingEnter = (isSendDisable, isReportReadyForDisplay) => {
if (isSendDisable || !isReportReadyForDisplay) {
return;
} else {
// Hanle submit and clean up logic
}
};
Job added to Upwork: https://www.upwork.com/jobs/~01e5b7548a5c671a9e
Triggered auto assignment to @jliexpensify (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Platforms
in OP are ✅)Triggered auto assignment to @sakluger (External
), see https://stackoverflow.com/c/expensify/questions/8582 for more details.
Triggered auto assignment to Contributor-plus team member for initial proposal review - @robertKozik (External
)
Proposal by: @hungvu193 Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1694937956481939
Composer: Clicking on Send button make the error disappear while actually it should do nothing.
We're setting disable style for our Pressable inside SendButton here.
https://github.com/Expensify/App/blob/c77814fd5e643cba78e8c8294370d78f633a59c5/src/pages/home/report/ReportActionCompose/SendButton.js#L57-L64
However, we're using GestureDetector
's gesture to handle the click on Send button, so even the send button is disabled, it still perform the gesture and in our Tap gesture which caused this issue:
https://github.com/Expensify/App/blob/c77814fd5e643cba78e8c8294370d78f633a59c5/src/pages/home/report/ReportActionCompose/SendButton.js#L36-L49
Solution 1:
We should disable the Tap gesture if isDisabledProp
is true:
const Tap = Gesture.Tap()
.enabled(!isDisabledProp)
.onEnd(() => {
Solution 2:
Add an early return when isDisabledProp
is true inside onEnd
function:
.onEnd(() => {
'worklet';
if (isDisabledProp) {
return;
}
N/A
This has the same root cause as https://github.com/Expensify/App/issues/26960 where if the send button is set to disabled, the tap action still gets executed.
@robertKozik based on the comment above, this sounds like it could be a dupe? Shall we close this or maybe put this on hold?
@jliexpensify I think App allows to write and send message in skeleton view
is expected behavious
No, it's not a duplicate. The issue that @akinwale linked did contain a proposal with a solution that would also fix our issue. However, that issue as a whole was closed because it pertained to expected behavior. I'll review the proposals today.
Any thoughts on the proposals @robertKozik ?
@jliexpensify, @robertKozik Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Hi @DylanDylann @hungvu193! Both of you siggested simillar solution for this problem, which potencially suffers from the same problem. Per #26960 issue we want the send button to be accessible when chat is loading.
@hungvu193 your solution is passing the isDisabledProp
which would disable the send button while loading
@DylanDylann is the isSendDisabled
variable identical with isDisabledProp
? If yes, it will case the same problem.
If you could update your proposal so that send button won't be disabled during chat loading, but be disabled only after clicking on it
@robertKozik Also please note that my proposal will fix the case pressing the ENTER button, not only clicking on "Send" button. Because pressing the ENTER button or clicking on the Send button should be the same, right?
@robertKozik
If you could update your proposal so that send button won't be disabled during chat loading, but be disabled only after clicking on it
<ReportFooter {... currentProps} isReportReadyForDisplay={isReportReadyForDisplay} />
handleClickingOnSendOrPressingEnter
in my proposal to:
const handleClickingOnSendOrPressingEnter = (isSendDisable, isReportReadyForDisplay) => {
if (isSendDisable || !isReportReadyForDisplay) {
return;
} else {
// Hanle submit and clean up logic
}
};
Ok, Updated my proposal:
Composer: Clicking on Send button make the error disappear while actually it should do nothing.
We're setting disable style for our Pressable inside SendButton here.
https://github.com/Expensify/App/blob/c77814fd5e643cba78e8c8294370d78f633a59c5/src/pages/home/report/ReportActionCompose/SendButton.js#L57-L64
However, we're using GestureDetector
's gesture to handle the click on Send button, so even the send button is disabled, it still perform the gesture and in our Tap gesture which caused this issue:
https://github.com/Expensify/App/blob/c77814fd5e643cba78e8c8294370d78f633a59c5/src/pages/home/report/ReportActionCompose/SendButton.js#L36-L49
First of all we should update the logic of isSendDisabled
as below:
// with isReportReadyForDisplay is passed down from ReportScreen.
const isSendDisabled = !isReportReadyForDisplay || isCommentEmpty || isBlockedFromConcierge || disabled || hasExceededMaxCommentLength;
After that we can do as below:
Solution 1:
We should disable the Tap gesture if isDisabledProp
is true:
const Tap = Gesture.Tap()
.enabled(!isDisabledProp)
.onEnd(() => {
Solution 2:
Add an early return when isDisabledProp
is true inside onEnd
function:
.onEnd(() => {
'worklet';
if (isDisabledProp) {
return;
}
N/A
@jliexpensify, @robertKozik Eep! 4 days overdue now. Issues have feelings too...
Thank you both for updating the proposals! I think I will suggest the @DylanDylann proposal, as it's not only fixes the issue, but as well refactor the code with unifying the submit functions.
Selected proposal: https://github.com/Expensify/App/issues/27779#issuecomment-1725481804
🎀 👀 🎀 C+ reviewed
Triggered auto assignment to @aldo-expensify, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
📣 @DylanDylann 🎉 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 📖
📣 @hungvu193 🎉 An offer has been automatically sent to your Upwork account for the Reporter role 🎉 Thanks for contributing to the Expensify app!
@robertKozik PR https://github.com/Expensify/App/pull/28681 is ready for review
Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:
On to the next one 🚀
Should @DylanDylann be paid a reporting bonus here? It looks like there was a ~3 day delay for @robertKozik to review the PR cc @aldo-expensify for your thoughts
Reviewing
label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.79-5 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2023-10-16. :confetti_ball:
After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
For reference, here are some details about the assignees on this issue:
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
- [X] [@robertKozik] The PR that introduced the bug has been identified. Link to the PR: https://github.com/Expensify/App/pull/25758
- [X] [@robertKozik] 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: https://github.com/Expensify/App/pull/25758/files#r1351875313
- [X] [@robertKozik] A discussion in #expensify-bugs 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] [@robertKozik] Determine if we should create a regression test for this bug. I don't think we need new test here
- [X] [@robertKozik] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again. N/A
@aldo-expensify Please help check https://github.com/Expensify/App/issues/27779#issuecomment-1752353186 when you have a chance
Hi @DylanDylann - I actually queried this with another GH (same situation, delay in C+) and was told that bonuses only apply if the Expensify Engineer is delayed. Sorry!
Payment Summary:
Yeah thanks @jliexpensify
All paid and job closed!
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:
Expand button should be visible after clicking Send button
Actual Result:
Expand button disappear after clicking even when composer has error
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: 1.3.71.5 Reproducible in staging?: y Reproducible in production?: y If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/ea69cd7e-99b2-47be-abcc-e918e153341f
https://github.com/Expensify/App/assets/93399543/4560eefb-e5fa-4c5f-8d6c-e6e5661a0f5b
Expensify/Expensify Issue URL: Issue reported by: @hungvu193 Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1694937956481939 https://expensify.slack.com/archives/C049HHMV9SM/p1695124790291359
View all open jobs on GitHub
Upwork Automation - Do Not Edit