-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
fix: do not ovelap hoverlabels for different tracetypes #6954
Merged
Merged
Changes from 4 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
8d1a49e
fix: do not ovelap hoverlabels for different tracetypes
mbant 74dc83d
chore: draftlog
mbant 6cfc094
fix: var instead of let
mbant 33b28ec
fix: fix eslint mismatch
mbant 4321451
fix: simplify label grouping condition
mbant 0631d43
Merge branch 'plotly:master' into issue-6917
mbant 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 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 @@ | ||
- fix for excessive hoverlabel removal and overlap for plots with both `scatter` and `bar` traces which reported in [#6917](https://github.com/plotly/plotly.js/issues/6917). |
This file contains 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 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
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.
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 don't understand this actually - I only see us using
crossAxKey
as a variable name, not a key in these point objects.Given that this change fixes the behavior, you've clearly identified that this condition is the one causing this bug, but AFAICT the change is equivalent to just
if(topOverlap > 0.01)
- and maybe that's right? Maybe thepmin
/pmax
conditions are no longer useful (which presumably means the commentOnly group points that lie on the same axes
is also no longer what we want) but that's the question to answer before we move forward with this.@archmoj I've forgotten the details of this, and anyway it changed recently with the
hoversubplots
work, but if you can convince yourself that removing this condition entirely is correct in all the cases we care about (in addition to the case being tested here, I'd focus on overlaid subplots with points at the same position on screen but either different x axis, different y axis, or both) then go for it!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.
100% agreed on the condition. It's been a while so not sure why that was there ...
I pushed a commit to simplify the condition (and thus removing the comment) if that helps with testing / convincing; I will have time to pick this up again in the following days so @archmoj let me know if I can help with anything!