Skip to content
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

Tooltip gets stuck on the page fix #12572

Merged
merged 6 commits into from
Nov 11, 2022
Merged

Tooltip gets stuck on the page fix #12572

merged 6 commits into from
Nov 11, 2022

Conversation

getusha
Copy link
Contributor

@getusha getusha commented Nov 8, 2022

Details

#12025 (comment)

Fixed Issues

PROPOSAL: GH_LINK_ISSUE(COMMENT)

Tests

  1. Decrease the screen size
  2. Hover over any contact at chat navigator
  3. When the tooltip appears open the chat
  4. Hover at back button until the tooltip shows up then press back
    The Tooltip should disappear after clicking on the chat / pressing back and only re-appear when hovering clickable items
  • Verify that no errors appear in the JS console

QA Steps

Same as tests

  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist

The reviewer will copy/paste it into a new comment and complete it after the author checklist is completed

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots

Web

-3-New-Expensify
-3-New-Expensify (1)

Mobile Web - Chrome

Mobile Web - Safari

Desktop

20221109_215653.mp4

AnyConv com__Screenshot 2022-11-09 at 9 50 53 PM (1)
AnyConv com__res 2022-11-09 at 9 50 55 PM (1)

iOS

Android

@getusha getusha requested a review from a team as a code owner November 8, 2022 22:15
@github-actions
Copy link
Contributor

github-actions bot commented Nov 8, 2022

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

@melvin-bot melvin-bot bot requested review from PauloGasparSv and removed request for a team November 8, 2022 22:15
@getusha
Copy link
Contributor Author

getusha commented Nov 9, 2022

recheck

@PauloGasparSv
Copy link
Contributor

Hey @getusha, hope you are doing well.
Sorry for not commenting here sooner!

  • Do you mind adding evidences for Desktop too? Also checking the missing items of your PR Author Checklist section? (I know this is just a Web and Desktop issue but we need to check all of them)

  • Also, in the Fixed Issues section, can you change the content to the URL itself after the dollar sign like this:

    $ [PAID] [$1000] Bug: Tooltip gets stuck on the page reported by @Puneet-here #12025
    PROPOSAL: GH_LINK_ISSUE(COMMENT)

  • Do you mind adding a couple more items to the Tests describing what behavior should be happening after the click? I think it would be something like "The clickable mouse tooltip should disappear after clicking on the chat and only re-appear when hovering clickable items"

  • One last thing, can you comment in the QA Steps section something like "Same as Tests" so no one thinks there are NO QA steps?

@mountiny
Copy link
Contributor

mountiny commented Nov 9, 2022

@getusha Great to see your first PR! For your next one, please make sure to link the issue correctly as described in the template, like so: $ https://github.com/Expensify/App/issues/12025

Thank you!

@getusha
Copy link
Contributor Author

getusha commented Nov 9, 2022

@PauloGasparSv Thanks, I will add the listed requests

@getusha
Copy link
Contributor Author

getusha commented Nov 9, 2022

Done @PauloGasparSv
Sorry for the delay.

@getusha
Copy link
Contributor Author

getusha commented Nov 10, 2022

@PauloGasparSv @rushatgabhane @chiragsalian
Can we get this reviewed? Thank you.

rushatgabhane
rushatgabhane previously approved these changes Nov 10, 2022
Copy link
Member

@rushatgabhane rushatgabhane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chiragsalian LGTM! 🎉

Web
Screen.Recording.2022-11-11.at.1.06.47.AM.mov
mWeb
Screen.Recording.2022-11-11.at.1.10.55.AM.mov
iOS

NA

Android

NA

Desktop
Screen.Recording.2022-11-11.at.1.12.49.AM.mov

PR Reviewer Checklist

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Co-authored-by: Rushat Gabhane <rushatgabhane@gmail.com>
Co-authored-by: Rushat Gabhane <rushatgabhane@gmail.com>
rushatgabhane
rushatgabhane previously approved these changes Nov 10, 2022
@getusha
Copy link
Contributor Author

getusha commented Nov 10, 2022

Thank you @rushatgabhane
All set?

@rushatgabhane
Copy link
Member

@getusha it's @chiragsalian / @PauloGasparSv's to review

PauloGasparSv
PauloGasparSv previously approved these changes Nov 10, 2022
Copy link
Contributor

@PauloGasparSv PauloGasparSv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Only uploading footage from web and desktop.
All yours @chiragsalian

PR Reviewer Checklist

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Web

Web.mov

Desktop

Desktop.mov

@rushatgabhane
Copy link
Member

@chiragsalian let's get this merged today :)

chiragsalian
chiragsalian previously approved these changes Nov 11, 2022
Copy link
Contributor

@chiragsalian chiragsalian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, waiting for GH actions to finish.

Co-authored-by: Rushat Gabhane <rushatgabhane@gmail.com>
@rushatgabhane
Copy link
Member

rushatgabhane commented Nov 11, 2022

@getusha please find a fix for it if you can, meanwhile I'll try to do the same

@rushatgabhane
Copy link
Member

Created a fix PR - #12677

@getusha can you please see if it'll cause another regression - #6083

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

Sure @rushatgabhane working on it. will update you

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

Looks like we have the resetsOnClickOutside prop applied inside ReportActionItem's Hoverable we need to pass a new prop to check if the prop is from the Tooltip

@rushatgabhane rushatgabhane mentioned this pull request Nov 11, 2022
92 tasks
@rushatgabhane
Copy link
Member

@getusha we can also remove resetsOnClickOutside from ReportActionItem's Hoverable, right?

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

That don't seem like a good idea, instead we should add isTooltipComponent prop to the Hoverable inside the Tooltip
And
if(this.props.resetsOnClickOutside && this.props.isTooltipComponent) {

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

Should I raise new PR for this?

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

I am about to raise the new PR

@rushatgabhane
Copy link
Member

sorry for the deleted comments.

That don't seem like a good idea

@getusha im curious to know why not?

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

There might be something related to it?

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

Can you raise the new PR @rushatgabhane ?

@rushatgabhane
Copy link
Member

@getusha it's here - #12677

@rushatgabhane
Copy link
Member

There might be something related to it

That makes sense, my PR might cause #5972 again.

But in my tests so far, it doesn't cause it. So i think we're good to go.

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

Great, I think we should go with that.
Will check id more regressions occur

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

Well so let's take the new prop approach

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

Here is the new PR #12681
@rushatgabhane

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

We can remove the other one?

@rushatgabhane
Copy link
Member

@getusha sorry that i wasn't clear enough.

I think we should go with #12677

because it doesn't need the tooltipComponent prop, so it's cleaner.

@getusha
Copy link
Contributor Author

getusha commented Nov 11, 2022

@rushatgabhane
Great is that not causing additional bugs?

@rushatgabhane
Copy link
Member

rushatgabhane commented Nov 11, 2022

@getusha i thought my pr would cause #5972

but while testing, it wasn't causing.

i could be wrong, so please correct me

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @chiragsalian in version: 1.2.28-0 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 failure ❌
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

🚀 Deployed to staging by @chiragsalian in version: 1.2.28-0 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@OSBotify
Copy link
Contributor

🚀 Deployed to production by @roryabraham in version: 1.2.28-2 🚀

platform result
🤖 android 🤖 success ✅
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

@mollfpr
Copy link
Contributor

mollfpr commented Jan 17, 2023

Comment regarding #13146 BZ checklist.

This PR has been identified for introducing the #13146 issue. This is an edge case, where resetting the hoverable state click on Chrome the hoverable state will be active again but in Safari the hoverable state is active after some movement.

The explanation and the example can be checked on this comment.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants