-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HOLD for payment 2023-06-01] [$4000] After returning to a setting from a profile, the tooltip loses position on the profile image when you hover the mouse for the first time. #15229
Comments
Triggered auto assignment to @CortneyOfstad ( |
Bug0 Triage Checklist (Main S/O)
|
@CortneyOfstad Whoops! This issue is 2 days overdue. Let's get this updated quick! |
Was OoO — tackling this now! |
Job added to Upwork: https://www.upwork.com/jobs/~0175f90dca3be1912f |
Current assignee @CortneyOfstad is eligible for the External assigner, not assigning anyone new. |
Triggered auto assignment to Contributor Plus for review of internal employee PR - @parasharrajat ( |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @rushatgabhane ( |
Triggered auto assignment to @MariaHCD ( |
The tooltip position is initialized only once during the first hover and the issue occurs because of the single initialization of the position of the tooltip so even if the target element position gets changed but tooltip position will not changed. I have tried to implement the same scenario using the same component and I am attaching the before and after the fix before: https://www.loom.com/share/f40dfbbdf9f94c07bee3e3c73285de34 after: https://www.loom.com/share/fa19295843f74158a8c4164546455202 |
ProposalPlease re-state the problem that we are trying to solve in this issue.After returning to a setting from a profile, the tooltip loses position on the profile image when you hover the mouse for the first time. What is the root cause of that problem?There 2 events that are causing this issue.
What changes do you think we should make in order to solve the problem?I propose 2 things:
What alternative solutions did you explore? (Optional)Moving the delay to |
Looks like something related to 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 Feel free to drop a note in #expensify-open-source with any questions. |
📣 @Litande! 📣 Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Format:
|
|
Contributor details |
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.17-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-06-01. 🎊 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.
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:
|
@parasharrajat can you complete the checklist above so I can pay and add regression (if applicable) before closing? |
[@parasharrajat] The PR that introduced the bug has been identified. Link to the PR: This bug is present since the first implementation. We never faced this up to this date. [@parasharrajat] 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: NA [@parasharrajat] 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: NA. This comes under edge-case scenarios and is rarely reproducible. [@parasharrajat] Determine if we should create a regression test for this bug. yes [@parasharrajat] 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. #15229 (comment) |
Regression Test Steps
Do you agree 👍 or 👎 ? |
It sounds super edge case, I'm not sure TBH. What do you think @anmurali ? Should we ask QA? |
No harm in adding a regression test proposal in a GH for Applause to evaluate. |
Also sent offers to @cubuspl42 and @parasharrajat for payment |
@anmurali I reported that bug |
Sent offer |
@anmurali offer accepted, Thank you |
Are we done here @anmurali ? |
Paid! |
@anmurali could you please close this bug contract on upwrok for me |
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:
(hover the image quickly)
Expected Result:
The tooltip should not lose the position even if you hover the image quickly.
Actual Result:
If you quickly hover over the image after returning from the profile, the tooltip loses position.
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: 1.2.73-1
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:
tooltip.mp4
2023-02-16.20-31-00.mp4
Expensify/Expensify Issue URL:
Issue reported by: @ayazhussain79
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1676563140766109
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: