[HOLD for payment 2023-10-10] [$1000] Task description label stays on top

[kavimuru]

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:

1. Click on FAB -> Click Assign Task
2. Add some Title & Description -> Click Next
3. On Confirm Task screen, Click on Description to update description
4. Clear description -> Click on Next button
5. You will now again be on Confirm Task page (with Empty Description)
6. Click back button -> See Description label floating

Expected Result:

Description label should be placed inside textfield if it’s empty

Actual Result:

Description label is floating over textfield (as it has some text in it, but there is no data inside textfield )

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.36-3
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

RPReplay_Final1688399438.mp4

XXFM1942.1.MP4

Expensify/Expensify Issue URL:
Issue reported by: @DinalJivani
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688400346545699

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~017f8f2919130b85b3
• Upwork Job ID: 1678898666441887744
• Last Price Increase: 2023-08-04

[melvin-bot]

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

[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

[kushu7]

Proposal

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

Task description label stays on top

What is the root cause of that problem?

App/src/components/TextInput/BaseTextInput.js

Lines 25 to 39 in 7e908b1

	const inputValue = props.value || props.defaultValue || '';
	const initialActiveLabel = props.forceActiveLabel || inputValue.length > 0 || Boolean(props.prefixCharacter);
	const [isFocused, setIsFocused] = useState(false);
	const [passwordHidden, setPasswordHidden] = useState(props.secureTextEntry);
	const [textInputWidth, setTextInputWidth] = useState(0);
	const [textInputHeight, setTextInputHeight] = useState(0);
	const [prefixWidth, setPrefixWidth] = useState(0);
	const [height, setHeight] = useState(variables.componentSizeLarge);
	const [width, setWidth] = useState();
	const labelScale = useRef(new Animated.Value(initialActiveLabel ? styleConst.ACTIVE_LABEL_SCALE : styleConst.INACTIVE_LABEL_SCALE)).current;
	const labelTranslateY = useRef(new Animated.Value(initialActiveLabel ? styleConst.ACTIVE_LABEL_TRANSLATE_Y : styleConst.INACTIVE_LABEL_TRANSLATE_Y)).current;
	const input = useRef(null);
	const isLabelActive = useRef(initialActiveLabel);

Problem is we don't update refs and values on Focus of screen.
When value removed by other page and we go back TaskDetails page stay mounted. thus BaseTextInput doesn't know it has to update label position. it just calculate on Mount currently.

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

I found a good solution.
We already have this useEffect that is responsible for activating/deactivating

App/src/components/TextInput/BaseTextInput.js

Lines 186 to 198 in cd09dc9

	const hasValueRef = useRef(inputValue.length > 0);
	// Activate or deactivate the label when the focus changes:
	useEffect(() => {
	// We can't use inputValue here directly, as it might contain
	// the defaultValue, which doesn't get updated when the text changes.
	// We can't use props.value either, as it might be undefined.
	if (hasValueRef.current || isFocused) {
	activateLabel();
	} else if (!hasValueRef.current && !isFocused) {
	deactivateLabel();
	}
	}, [activateLabel, deactivateLabel, inputValue, isFocused]);

We can just update hasValueRef using props.value changes using useEffect.
but we can't just directly update it, we have to check if inputValue is not equal to defaultValue and also check if props.value has any value.

     const hasValueRef = useRef(inputValue.length > 0);

    useEffect(() => {
        const hasValue = !!props.value
        if (inputValue !== props.defaultValue || hasValue) {
            hasValueRef.current = props.value && props.value > 0;
        }
    }, [props.value, inputValue, props.defaultValue])

It will activate/deactivate label properly

Video

vid.mov

What alternative solutions did you explore? (Optional)

We can use useFocusEffect hook to reAdjust label position by comparing previous and current ref value.

useFocusEffect(useCallback(() => {
// return early if ref and prop value is same or input is focused
    if (isLabelActive.current === initialActiveLabel || isFocused) return;
    hasValueRef.current = inputValue.length > 0;
    isLabelActive.current = initialActiveLabel
    if (initialActiveLabel) {
        activateLabel();
    } else {
        deactivateLabel();
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
}, [initialActiveLabel, inputValue,isFocused]))

[bernhardoj]

@hannojg maybe can take a look at this one too. We previously fixed this label issue here

[hannojg]

Yes thx for pinging me, I will look in a few hours into this!

[hannojg]

Looking into it now

[hannojg]

I do think I found a clean solution (note: I am the author of the original PR that caused the regression 😅 ):

Proposal

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

In our code we use uncontrolled and controlled TextInputs (i.e. providing a value prop or not). A recent change to our BaseTextInput component caused a regression where a controlled component wouldn't deactivate its label when the prop value has been reset to being empty (and the text input blurred).

What is the root cause of that problem?

Currently we are deciding on whether to deactivate the label based on two criteria:

• The text input isn't focused anymore
• We capture whether we have an input value in a ref, when TextInput#onChangeText gets called

In the second criteria lies the root cause. When we update the TextInputs value by the value prop onChangeText won't get called. Hence, when clearing the input with the value prop, the hasValueRef is still true.

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

Right now we have a useEffect that only triggers when the focus of the text input changes.
We extend that useEffect to also run when the value prop changes. When we detect that the value prop is empty and we have no focus, we will deactivate the label.

Before we were thinking we can't use the value prop in the useEffect because we wouldn't know whether the component is controlled or not, and thus could break the behaviour for uncontrolled text inputs. We need to consider both possibilities for having a value. The final result will look like this:

// We capture whether the input has a value or not in a ref.
// We need this information in case the component
// is uncontrolled (i.e. no value prop is supplied)
const hasValueRef = useRef(initialValue.length > 0);

const inputValue = props.value || '';
const hasValue = inputValue.length > 0 || hasValueRef.current;

// Activate or deactivate the label when either focus changes, or for controlled
// components when the value prop changes:
useEffect(() => {
    if (hasValue || isFocused) {
        activateLabel();
    } else if (!hasValue && !isFocused) {
        deactivateLabel();
    }
}, [activateLabel, deactivateLabel, hasValue, isFocused]);

This change also makes the code cleaner as now we can get rid of this useEffect:

App/src/components/TextInput/BaseTextInput.js

Lines 171 to 182 in a6ae94d

	useEffect(() => {
	// Handle side effects when the value gets changed programatically from the outside
	// In some cases, When the value prop is empty, it is not properly updated on the TextInput due to its uncontrolled nature, thus manually clearing the TextInput.
	if (inputValue === '') {
	input.current.clear();
	}
	if (inputValue) {
	activateLabel();
	}
	}, [activateLabel, inputValue]);

What alternative solutions did you explore? (Optional)

I had a look at the previous two proposals. Here are my notes (please note that they are meant completely judge free, we are just striving for the best possible solutions, and your guys' proposals were a great help in finding the final solution I came up with, so big thanks here 🙌 )

• @ginsuma Proposal: The proposal didn't really worked in my testing for fixing the issue, as setValue which gets called from onChangeText doesn't gets called necessarily when the value prop gets changed from the outside.
• @kushu7 Proposal: I think this could work, however it would leave other cases unhandled. Also giving a base text input knowledge about the current navigation focus feels somehow wrong and adds too much outside knowledge to a simple component in my opinion.

Screen.Recording.2023-07-06.at.10.51.29.mov

[melvin-bot]

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

[melvin-bot]

@michaelhaxhiu Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@michaelhaxhiu Still overdue 6 days?! Let's take care of this!

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~017f8f2919130b85b3

[melvin-bot]

Current assignee @michaelhaxhiu is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[michaelhaxhiu]

@hannojg has given some great context above on the origin story. I'm not sure if we should just assign Hanno to see it through at this point? Thoughts @abdulrahuman5196 ?

[michaelhaxhiu]

If we want group input, let's feel inclined to post on the ongoing slack thread here (and post to channel)

https://expensify.slack.com/archives/C049HHMV9SM/p1688400346545699

[abdulrahuman5196]

Will look into this in couple of hours

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[michaelhaxhiu]

just dm'ed @abdulrahuman5196 and hoping for some eyes on this soon!

[abdulrahuman5196]

We have been waiting on @hannojg to solve merge conflicts

cc: @michaelhaxhiu @hayata-suenaga

[michaelhaxhiu]

This isn't done yet, but it's progressing. I'm preparing to go OOO by end of the week for my sabbatical, so I'm going to remove my assignment and leave this with @muttmuure.

Next steps are similar to before, but we are closer :)

1. @hannojg is going to complete the internal PR to solve this.
2. After that's done, we'll process payment to the C+ ($1000 for @abdulrahuman5196) and Bug reporter ($250 for @DinalJivani)

[hannojg]

PR is resolved and working now 👍

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.76-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix(#22204): Toggle label correctly #24199

If no regressions arise, payment will be issued on 2023-10-10. 🎊

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.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @hannojg does not require payment (Contractor)
• @abdulrahuman5196 requires payment
• @DinalJivani requires payment

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot]

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:

• [@abdulrahuman5196] The PR that introduced the bug has been identified. Link to the PR:
• [@abdulrahuman5196] 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:
• [@abdulrahuman5196] 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:
• [@abdulrahuman5196] Determine if we should create a regression test for this bug.
• [@abdulrahuman5196] 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.
• [@muttmuure] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[abdulrahuman5196]

The PR that introduced the bug has been identified. Link to the PR:

#20186

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:
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:

#20186 (comment)

Determine if we should create a regression test for this bug.
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.

No. Not beneficial to add regression test for this minor bug

[melvin-bot]

@hannojg, @abdulrahuman5196, @muttmuure, @hayata-suenaga Eep! 4 days overdue now. Issues have feelings too...

[hayata-suenaga]

seems we don't need regression test

are we paying for payment?

[abdulrahuman5196]

@muttmuure Gentle ping on payment processing. Waiting for over a week.

[muttmuure]

Looking now

[muttmuure]

$1000 - C+ @abdulrahuman5196

[muttmuure]

Invited to Upwork job

[abdulrahuman5196]

@muttmuure accepted

[muttmuure]

Paid

[DinalJivani]

@muttmuure
Reporting bonus is pending here

[muttmuure]

Invited!