[HOLD for payment][$1000] Web - The popup menu overlaps the + icon on room

[kbecciv]

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. Go to staging dot on web chrome and login with User A
2. Create a new room in public mode
3. Go to header and copy the share URL
4. Important step- Now click on + icon on the room so that a popup menu appears. Notice that the 'Attachment' is shown above the + icon (works well)- Do not click anywhere because it's important to have the popup opened
5. But now , open another web chrome and login with User B and paste the URL that you copied earlier so that User B can have access to the room
6. Now on User A side, notice that 'Split bill' also arises on popup and notice that the menu popup overlaps the + icon of the room.
7. If you click somewhere on the screen and again click on + icon, you'll notice this time, the menu doesn't overlaps the + icon and is shown above it

Expected Result:

The popup menu should not overlap the + icon on room when User B joins it

Actual Result:

The popup menu overlaps the + icon on room

Workaround:

Unknown

Platforms:

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

• [ ] Android / native
• [ ] Android / Chrome
• [ ] iOS / native
• [ ] iOS / Safari
• [x] MacOS / Chrome / Safari
• [ ] MacOS / Desktop

Version Number: 1.3.33-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

https://github.com/Expensify/App/assets/93399543/d132a818-32c3-4d38-a355-df0bfe34f660

https://github.com/Expensify/App/assets/93399543/79b704e2-ede9-4d13-bec0-c7669da7247e

Expensify/Expensify Issue URL: Issue reported by: @priya-zha Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687846865181099

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01a5b67e57313ec40b
• Upwork Job ID: 1674159615707922432
• Last Price Increase: 2023-08-13
2023-07-26
• Automatic offers:
• abdulrahuman5196 | Reviewer | 25812254
• priya-zha | Reporter | 25812259

[waterim]

@s-alves10 Sure, here it is

https://github.com/Expensify/App/assets/39777589/d46fa0ce-f1f7-4ca6-9cd0-259b234ef246

[s-alves10]

@waterim

Looks great. Can you explain your logic in words? How can the popover be positioned correctly without recalculating the width and height when its size changes dynamically?

We are using PopoverMenu component heavily across the project and this component uses PopoverWithMeasuredContent. And there are many other scenarios that menu height is changed dynamically. And there are some examples that menus are aligned from bottom like ThreeDotsMenu. Are you sure your solution works for them as well?

cc @abdulrahuman5196

[waterim]

@s-alves10 For all cases we need to test it carefully. "How can the popover be positioned correctly without recalculating the width and height when its size changes dynamically?" now without any additional code new menuItem just shifting to the bottom, because we are calculating anchorPosition from the top, I mean we are adding "top" style for an absolute div in here. It means when new menuItem or whatever is coming dynamically it comes from the top but value is not recalculating and all this content just shifting to the bottom, because "top" style still the same. With my solution we are changing behaviour of the popover, because we are adding "bottom" style to the container itself, it means when new menuItem is coming dynamically it will be added correctly to the Popover and no shifting present to the bottom, because "bottom" style still the same as it was before.

Can you please provide me with a place where I can test this ThreeDotsMenu?

[s-alves10]

Go to settings -> workspace -> select one workspace

[waterim]

@s-alves10 thank you

[s-alves10]

How will you explain if this menu items change dynamically?

[neil-marcellini]

Let's stop 🛑 the conversation here, it's cluttering up GH. Follow along in Slack here.

[neil-marcellini]

From Slack it sounds like @waterim has a plan and I asked him to post a proposal. C+ and I will review and get this moving.

[waterim]

Proposal

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

The popup menu overlaps the + icon on room when children is adding dynamically.

What is the root cause of that problem?

https://github.com/Expensify/App/blob/6c9e459f8114f1cd2986a83ede1d73fb150aa366/src/components/PopoverWithMeasuredContent.js#L152 In PopoverWithMeasuredContent component, onLayout is called only on an invisible View for a first render setting isContentMeasured to true. Thats why width and height are not calculated dynamically when children(Menu Items) is changing.

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

The simplest solution here will be to change stylings for shiftedAnchorPosition: change top shift to bottom because from bottom we don't need to change a position of the popover from top each time menuItems changes. https://github.com/Expensify/App/blob/6c9e459f8114f1cd2986a83ede1d73fb150aa366/src/components/PopoverWithMeasuredContent.js#L131-L133 This part of the code should look like this:

    const shiftedAnchorPosition = {
        left: adjustedAnchorPosition.left + horizontalShift,
        bottom: windowHeight - (adjustedAnchorPosition.top + popoverHeight) - verticalShift,
    };

Additionally we can wrap the Popover child in a View with onLayout={measurePopover}, like this:

         <Popover
            // eslint-disable-next-line react/jsx-props-no-spreading
            {...props}
            anchorPosition={shiftedAnchorPosition}
         >
            <View onLayout={measurePopover}>{props.children}</View>
        </Popover>

This solution fixes the issue with recalculating and glitches and works smoothly for all types of the Popovers.

Example how it works:

https://github.com/Expensify/App/assets/39777589/631ef1bf-43aa-4051-b695-053e9a70e390

https://github.com/Expensify/App/assets/39777589/67ae97bd-f6e0-4a40-b598-a203224653ba

[waterim]

@neil-marcellini Hello, here is an updated proposal with combined solution as we discussed.

[neil-marcellini]

Great thanks, @abdulrahuman5196 will review first and then I will.

[abdulrahuman5196]

Hi, Sorry Missed this one. Will check and update tomorrow.

[s-alves10]

@waterim Can you upload a video for this scenario?

[waterim]

@s-alves10 Sure, updated a proposal

[sakluger]

Bump @abdulrahuman5196

[s-alves10]

@abdulrahuman5196

I think my solution enhances the reusability of the PopoverWithMeasuredContent component and a good option for minimizing the recalculation as possible Let me know your thought, please

[melvin-bot[bot]]

Current assignee @sakluger is eligible for the Bug assigner, not assigning anyone new.

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[sakluger]

I'm assigning a new C+ to help keep this moving forward. @s77rt can you let me know if you have the time to review the most recent proposals with priority? Thanks!

[abdulrahuman5196]

Hey, Sorry for the delay folks. I will try to close it out today @sakluger since already spent lot of time reviewing here. Or else happy for @s77rt to take it over.

[abdulrahuman5196]

@waterim 's proposal here - https://github.com/Expensify/App/issues/21809#issuecomment-1668478215 looks good and works well. I tested on how many times the measurement is called as well, it seems that the re-measurement is called only during items changes, which is minimal case. AFAIK, it doesn't seem to impact the performance as I was worried.

🎀 👀 🎀 C+ Reviewed

cc: @neil-marcellini

[melvin-bot[bot]]

Current assignee @neil-marcellini is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[abdulrahuman5196]

https://github.com/Expensify/App/issues/21809#issuecomment-1676042586 cc: @sakluger

[s-alves10]

@waterim 's solution was already discussed by other contributors. Changing anchor bottom or top isn't important here, I think. I really don't understand your decision.

@abdulrahuman5196 Please tell me if I missed something

[s77rt]

@abdulrahuman5196 Given you have submitted an approval on a proposal already I will be unassigning myself here. Feel free to tag me if anything. Thanks!

[abdulrahuman5196]

@s-alves10

Changing anchor bottom or top isn't important here, I think.

Change the anchor position alone didn't work as you had already pointed out in slack(Which was their first solution), but their latest proposal with combined approach of layout measurement solves the issue. And currently it is the simple and best available solution so far.

On a side note: Regarding your proposal here https://github.com/Expensify/App/issues/21809#issuecomment-1661536110 , I am not aligned on the solution. Since it like we are trying to do solutions/workarounds to not directly compare children and also not aligned on the below point. Popover should be self-sufficient to re-align itself when its elements changes instead of parent providing the information.

I think the best way to do this is to let parent component determine when to measure.

[s-alves10]

@abdulrahuman5196

Thank you for your explanation.

I'm not saying my solution should be selected. The selected solution has the one difference: anchor position. We had a similar discussions and simple solutions already.

I am not aligned on the solution. Since it like we are trying to do solutions/workarounds to not directly compare children and also not aligned on the below point. Popover should be self-sufficient to re-align itself when its elements changes instead of parent providing the information.

Maybe. But the parent knows when we should remeasure the wrapper exactly.

Anyway, I respect the decision. I wanted to say the review process should be fair. If the RCA is correct and the solutions are similar, I think the first proposal should be selected.

[abdulrahuman5196]

I'm not saying my solution should be selected. The selected solution has the one difference: anchor position. We had a https://github.com/Expensify/App/issues/21809#issuecomment-1612729277 and simple solutions already.

Yes. I knew this already and pointed it out in slack as well. https://expensify.slack.com/archives/C01GTK53T8Q/p1691086409147509?thread_ts=1691081056.624619&cid=C01GTK53T8Q

But without anchor position it is not working properly which i tested yesterday also. And the anchor position shift is not a minor change nor a PR level comment. So IMO the selected proposal can be considered a new proposal.

[neil-marcellini]

@waterim 's proposal here - https://github.com/Expensify/App/issues/21809#issuecomment-1668478215 looks good and works well.

I agree 👍

[sakluger]

Just summarizing where we are - @waterim's PR is still in review, should get merged after a few more tests.

The timeline is a bit funky on this one. @neil-marcellini approved the proposal on Aug 17, but there was already a draft PR on Aug 14. There won't be an efficiency bonus on this one, but given the complexity, there definitely shouldn't be a penalty either.

[aimane-chnaif]

@waterim is from callstack and agency PRs don't apply bonus/penalty timeline rule

[melvin-bot[bot]]

This issue has not been updated in over 15 days. @sakluger, @neil-marcellini, @waterim, @abdulrahuman5196 eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[abdulrahuman5196]

@sakluger I think the payment is pending on this issue?

[abdulrahuman5196]

The PR that introduced the bug has been identified. Link to the PR: 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:

Not regression

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. Minor case won't need any regression test

[sakluger]

Looks like the automation missed this GH issue. Thanks @abdulrahuman5196 for the bump in Slack.

Summarizing payouts for this issue:

Bug reporter: @priya-zha $250 (paid via Upwork) Contributor: @waterim $1000 (contractor from Callstack, no payment required) Contributor+: @abdulrahuman5196 $1000 (paid via Upwork)

@waterim could you please share your Upwork profile so that I can send you an offer?

[aimane-chnaif]

@waterim is from callstack. No upwork

[abdulrahuman5196]

@sakluger We can close this issue.

[sakluger]

Got it, thanks for clarifying! Closing out 👍