-
Notifications
You must be signed in to change notification settings - Fork 646
TooltipV2: Hide Tooltip when menu is active
#7142
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
Merged
Merged
Changes from 10 commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
7bb11f9
Hide menus or "popups" when active, based on ARIA attributes provided
TylerJDev 968fcd2
Add `aria-haspopup="menu"
TylerJDev b3f7042
Add changeset
TylerJDev 9e892b4
Add back `aria-haspopup="true"`
TylerJDev 6da129f
update changeset
TylerJDev 89fdb06
Only apply if `aria-expanded="true"
TylerJDev 42f261d
Check for both boolean and string `true`
TylerJDev 097f616
Maybe fix react 19 test?
TylerJDev 1ec498d
Modify solution to use prop
TylerJDev 417bea6
Update changeset
TylerJDev eb209fe
Add prop as private
TylerJDev File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| --- | ||
| '@primer/react': minor | ||
| --- | ||
|
|
||
| IconButton: Hide tooltip when popup is open via new `closeTooltip` prop in `Tooltip`. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this an internal mechanism instead of part of the API? Don't want to accidentally introduce/promote a way of disabling tooltips unless that is the explicit intention.
If it exists, it will get used; we still have 57 instances of unsafeDisableTooltip that have not been cleaned up 😅
Possible solutions:
:has(button[aria-expanded=true])work?_privateDisableTooltipprop that looks private and we don't document (we have a similar prop in ActionList)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely can! I'm thinking option 3 might be the best, but let me know what you think.
This could work, we are exposed to
TooltipContext, which currently provides the ID. We're mostly relying on what ActionMenu (throughAnchoredOverlay) provides toIconButtonto determine if it should be hidden or not (ifaria-expanded="true"andaria-haspopup="true"exist on the IconButton)I'm not too sure what we could pass to context for Tooltip here 🤔 We could check within Tooltip for if it's a menu, but that might add more logic to handle. Let me know what you think though 👀
This would definitely work! The only concern is how we'd scope it to only apply if it's both an
IconButtonand that button triggers a menu.e.g.
:has(button[aria-expanded=true][aria-haspopup=true])There doesn't' seem to be a good identifier between the buttons 🤔
This works! Ideally we wouldn't have to use a prop to begin with, but I figured that this approach is less likely to interfere with any existing
TooltiporIconButtoninstances.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data-component="IconButton"?The provider is in the tooltip which wraps the button, so would have to pass a function down in context for button to call. Not my favorite.
Good backup if the css other does not work reliably
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried the CSS way, but since the Tooltip is a sibling of the IconButton it's not as feasible of a solution 😭
Example 1:
&[popover]:not(:has(> [data-component="IconButton"][aria-haspopup='true'][aria-expanded='true'])):popover-open- this would apply if the tooltip was wrapped around the IconButton, but it's a sibling.Example 2:
&[popover]:not(:has(~ [data-component="IconButton"][aria-haspopup='true'][aria-expanded='true'])):popover-open- this only targets siblings after the Tooltip in the DOM, components using Tooltip will always come before, not after.I might be missing another way, but I think the prop might be the option to run with.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch, fair enough!