Skip to content

Legend drag gets misaligned in the bottom 2/3 of the plot #1438

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

Closed
alexcjohnson opened this issue Mar 2, 2017 · 3 comments
Closed

Legend drag gets misaligned in the bottom 2/3 of the plot #1438

alexcjohnson opened this issue Mar 2, 2017 · 3 comments
Labels
bug something broken

Comments

@alexcjohnson
Copy link
Collaborator

Another one discovered while fiddling re: #1432 - If you make a plot with a legend (perhaps http://localhost:3000/devtools/test_dashboard/#legend_style) and make it editable so you can drag the legend (Plotly.newPlot(gd, gd.data, gd.layout, {editable: true})) you can drag the legend around anywhere in the top 1/3 of the plot area and it positions itself correctly. But if you drag it to the middle or bottom of the plot area, it jumps back up a bit when you drop it.

This comes from a miscalculation with yanchor: auto, which is the default yanchor value, and means that when you're in the middle third of the plot, the position (legend.y) is anchored to the middle of the legend, and when you're in the bottom third it's anchored to the bottom of the legend. This setting is designed to make it easy to keep the legend aligned near a corner of the plot even when the plot size might change.

It seems like x also has this problem, but it has an additional problem that xanchor defaults to left rather than auto as it should. That may be a tougher one to solve, as we can't just change the default without breaking backward compatibility for some plots...

Annotations (when paper-referenced with no arrow) have the same auto anchor behavior, but they do not have either of these bugs.

@alexcjohnson alexcjohnson added the bug something broken label Mar 2, 2017
@etpinard
Copy link
Contributor

cc our new legend expert @antoinerg

@etpinard
Copy link
Contributor

etpinard commented Sep 30, 2019

Looks like #4160 made this behave a little bit better:

Peek 2019-09-30 16-59

... but didn't fix it entirely. This bug is essentially what @antoinerg noticed while reviewing in #4160 in #4160 (comment)

@gvwilson
Copy link
Contributor

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson

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

No branches or pull requests

3 participants