-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
patch(Coords): calc oCoords only with canvas ref #9380
Conversation
Build Stats
|
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't be simpler than this
done
can't accept a PR anymore that cites annoying error and bugs without specifing what is going on. |
Yes |
Motivation
Still working on controls and finding too many edgecasesI have a control that needs to access the canvas, so trying to do
fabricObject.canvas
needa to be safeguarded.And it makes absolutely no sense.
Because controls exist only on the canvas and need the canvas for vpt calculations etc. so without the canvas the controls are not used, calculated for no reason and produce wrong values
Since the introduction of layout in groups and nested targets, calls to setCoords are happening before adding an object to the canvas.
With the recent addition of #9376 you can use the object itself when calculating objects coordinates and this brings you to eventually evaluate the canvas of that object that is undefined in that moment.
For objects that do not do that we are still setting oCoords ignoring the canvas VPT and so potentially wrong.
Description
calc oCoords only when the canvas is available to the object
Since fabric calls setCoords when an object is added to canvas this PR makes no difference and is not breaking, but when working with custom logic the result will predictable and will save the developer from annoying errors and bugs.
Changes
Gist
In Action