[$500] Assign task - Invalid red dot appears by closing assign the tab when there's no prior action

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 1.4.1-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
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Issue found when executing PR #30679

Action Performed:

1. Navigate to staging.new.expensify.com and log in to an Expensifail account
2. Click the green plus button
3. Select "Assign task"
   4.Click outside the panel or the back button and hold, to close it
4. Repeat steps 2-4

Expected Result:

No red dot should be seen when closing the Assign task tab

Actual Result:

An invalid red dot appears briefly when closing the 'Assign task' tab when there is no prior action

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6284508_1700513827250.Assign_Task_-_Red_dot.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01690c0dbaf0deaaf7
• Upwork Job ID: 1726711332049424384
• Last Price Increase: 2023-11-20

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01690c0dbaf0deaaf7

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (External)

[cooldev900]

I am not able to reproduce it on dev.

[erquhart]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When clicking and holding back button or any spot outside of the RHN while assign task view is open, the Title field displays a validation error for as long as press/click is held.

What is the root cause of that problem?

Our form validation intentionally shows a validation error for required fields if they are focused and then blurred. We are autofocusing the field on form open, and by pressing a focusable element, such as outside of the RHN or the back button, we're blurring the input and triggering validation. Note that this is not really a bug, but a side effect of how the validation works.

What changes do you think we should make in order to solve the problem?

The only reason this seems jarring is because the user hasn't interacted with the form yet, and they didn't manually focus the field, so an error message isn't expected. I would not recommend special handling of this particular case, but that we stick to a design pattern.

We should decide either:

1. We want to continue validating required fields immediately on blur, and leave this as is, or
2. We don't like the side effects of showing missing required fields errors prematurely, so we'll show them only after the first form submission. This would only impact required field errors, all other error types would continue to show once the field is dirty as we currently do.

Going with approach # 2 means that, if the user hasn't submitted the form, they won't see the validation error that we currently do.

They will see it after first submission attempt, but will no longer be surprising because they would have already seen this error on submission and it makes sense. But it also means we're not giving immediate feedback as they focus in and out of required fields before the first submission. We already show (optional) for optional fields, implying that others are required, so I think this is an acceptable approach.

What alternative solutions did you explore?

If we really don't like the specific behavior outlined in this issue, but don't want to change our error validation pattern, we could:

1. Not autofocus this field on RHN open - this is probably very undesirable, not recommended, but we could do it.
2. Some kind of hack where we specifically recognize that the user is clicking away from the form. This will involve focus management trickery and pain, highly recommend against this kind of heavy solution to alleviate low/no impact behavior.

[tienifr]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Assign task - Invalid red dot appears by closing assign the tab when there's no prior action

What is the root cause of that problem?

When users blur the input, validate function is always triggered, that makes the error messages appear

App/src/components/Form/FormProvider.js

Line 272 in 72e73ae

onValidate(inputValues, !hasServerError);

What changes do you think we should make in order to solve the problem?

on web/desktop, onBlur of input is triggered first -> onClick of back button.

We should check if the relatedTarget (next focus element) does not contain the currentTarget (the input), then we can early return.

  if(!event.relatedTarget.contains(event.currentTarget)){
                        return;
                    }

I've tested all cases and it works well on web/desktop/mweb

Unfortunately, on native devices, onClick of back button is triggered first -> onBlur of input. And there's no such thing as the relatedTarget, that why on native we should detect if users have just clicked on the back button so we can avoid triggering onBlur

• defined new getJustClickedBackButton and setJustClickedBackButton in the new file named justClickedBackButton.ts,

• setJustClickedBackButton(true) in here

• setJustClickedBackButton(false) when HeaderWithBackButton is unmounted

• Update the condition above to

if((event.relatedTarget && !event.relatedTarget.contains(event.currentTarget)) || getJustClickedBackButton()){
   return;
}

Result

Web/Desktop
https://github.com/Expensify/App/assets/113963320/374d9429-5403-419e-add0-aa88dd2b7b10

Native/Ios
https://github.com/Expensify/App/assets/113963320/c22b33c0-d40b-43b0-acba-5a3f646a977b

[AmjedNazzal]

I'm not sure but perhaps someone can confirm this, but I think maybe this should wait until the From Provider Refractor is finalized since it will include the behaviour of NewTaskDetailsPage as mentioned in the comment

[parasharrajat]

I don't think this is a real issue. It's not worth changing. @garrettmknight Thoughts?

[erquhart]

The one thing that does feel off is that the invalid state is clearly visible while the RHN is closing on web/desktop, without holding the click.

Screen.Recording.2023-11-21.at.8.53.43.AM.mov

[garrettmknight]

@parasharrajat agreed, this isn't worth fixing right now.

[erquhart]

cool cool good talk