iPad - Chat - Delete comment option is not available in the menu in landscape mode

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Install test build
2. Login with an existing account
3. Open any conversation
4. Long tap on own message

Expected Result:

4 options should appear including "Delete Comment"

Actual Result:

Delete Comment option is not available in landscape mode

Workaround:

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

Platform:

Where is this issue occurring?

• iOS

Version Number: 1.0.95
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Expensify/Expensify Issue URL:
Issue reported by: Applause
Slack conversation:

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @sketchydroide (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[sketchydroide]

I can see this happens to some extent in the the iPhone as well. The text to delete the comment gets cut of when seeing the menu on the landscape.
Prety sure it's the size/offset calculation that is off in some way. Should be easy to fix, I'm setting this as an external.

[MelvinBot]

Triggered auto assignment to @adelekennedy (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[isagoico]

Adding the deploy blocker label since the issue is not on production

[OSBotify]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[parasharrajat]

Regression from #5032.

[isagoico]

This issue is also reproducible in the FAB menu. Split bill is not completely visible

[roryabraham]

We can't export this issue – it's an Hourly deploy blocker and needs to be addressed ASAP.

[roryabraham]

Regression from #5032.

Thanks @parasharrajat, confirmed this is true. I'm going to revert that PR, but maybe you deserve a small bonus for pointing me straight to the cause of this regression?

[mananjadhav]

Apologies I just saw this one. Thanks, @roryabraham @parasharrajat.

I've updated few things in #4456 (comment), which removes this code and has new updated code. I'll check for this regression as well.

[roryabraham]

@mananjadhav Up to you, but I think it might be simpler to create a separate PR to replace #5032. When in doubt, smaller PRs are better because they are easier to test, review, retroactively evaluate to see if they caused regressions, and to revert if necessary.

[mananjadhav]

@roryabraham Noted. I'll raise another PR to replace the old one.

[isagoico]

Retest was a pass 🎉

[roryabraham]

Okay, so I just wanted to clarify some things here:

• We've learned from experience that we can't let deploy-blocking issues be handled externally, because it causes too many delays in the process and slows down our deploy cycles.
• Our contributing guidelines currently state:

Note: If you post a proposed solution in an issue that has not been tagged with the External label, Expensify has the right to use your proposal to fix said issue, without providing compensation for your solution

So given that, the timeline for this issue was:

1. Issue created
2. Internal engineer assigns the External label to the PR (not a mistake, because it was not yet identified as a deploy blocker)
3. Issue is identified as a deploy blocker
4. @parasharrajat finds and posts the cause of the issue.
5. I notice that a deploy blocker is set to be handled externally, but know that we can't wait that long. So I remove the External label and handle myself.

So @parasharrajat assisted me in quickly resolving the blocker, and did so when the issue already had the External label. However, at that time, the issue should not have had the External label. We are going to resolve this by opening a job, and immediately paying it out, because I used a solution that @parasharrajat posted at a time when the issue had the External label. The fact that it should not have had that label in the first place was an error on our part. In the future, I think we need to resolve this by determining whether or not an issue is a deploy blocker before marking it as External.

[parasharrajat]

I am kind of fine without payment. I proposed early as deploy blockers are time-sensitive.

[adelekennedy]

Hey @parasharrajat I just created a job to pay you out for this (though I see your comment above!) do you mind accepting and I'll take care of payment as soon as possible?

[parasharrajat]

Thank you, guys. Appreciate it.