-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Fix NaN positions for shapes when dragging them. #7470
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
base: master
Are you sure you want to change the base?
Conversation
} else { | ||
modifyItem('y0', afterEdit.y0); | ||
modifyItem('y1', afterEdit.y1); | ||
} |
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.
Thanks @my-tien for the fix.
Two questions:
- Is a similar fix needed for the case of
path
? - Could you please add a test here:
describe('Activate and edit editable shapes', function() {
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'll have a look at path and adding a test. However, my fix is not yet correct. Among other things, afterEdit can be a shape with xref and yref paper apparently even if the ref was something different before. I'll have to see, how I can correctly translate the shift variables to paper as well. I will probably push some changes later today.
UPDATE: This is a separate bug. As mentioned further below, I'll open an issue for it 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.
For the path case the change is not necessary, because the shift properties are ignored if path is used instead of x0, x1, y0, y1.
Regarding the test, I added one with a test case that previously failed and now works. However, I am not sure how to test this locally because for some reason on my machine several Jasmine tests always fail. Could you please look at it on your end and make the necessary adjustments?
…e been converted to numerical before this point already. - Don't use plotinfo to retrieve the axis, somehow it doesn't always contain the correct axis information. Use `axis_ids.getFromId` instead. - Fix formatting
While working on this issue, I discovered a bug that existed also before version 2.24: A shape attached to xaxis 2 cannot be dragged. I'll open an issue later. EDIT: Here is the issue: #7472 (comment) |
(as is being done at other locations to test this)
@@ -1426,6 +1426,43 @@ describe('Activate and edit editable shapes', function() { | |||
|
|||
.then(done, done.fail); | |||
}); | |||
|
|||
it('should be possible to drag shapes referencing non-categorical axes', function(done) { |
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.
If you change it(
to fit(
then you could only run this test on your machine using
npm run test-jasmine draw_newshape
mode: "line", | ||
}, | ||
], | ||
layout: { |
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.
Please specify a width
and a height
for the graph.
FYI - The test didn't pass on my machine.
var shapes = gd._fullLayout.shapes; | ||
var obj = shapes[0]._input; | ||
print(obj); | ||
assertPos(obj.path, 'M250,300H1019V100H257.64Z'); |
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.
Instead of path
shouldn't we look into x & y parameter changes?
Some CircleCI fixes are added to the master. |
Fixes #7465
Previously, x0shift, x1shift, y0shift, y1shift or 0 were always applied to x0, x1, y0, y1 when dragging a shape.
However, as per the description of the shift attributes, they should only be applied for (multi-)category axes.
Also if x0,... are strings, a conversion to the corresponding category index was missing.