Skip to content
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 TypeError: fill.render is not a function #7220

Closed
wants to merge 1 commit into from
Closed

Fix TypeError: fill.render is not a function #7220

wants to merge 1 commit into from

Conversation

chr314
Copy link

@chr314 chr314 commented Jul 16, 2021

check if fill.render is function

fixing #7171 (comment)

@asturur
Copy link
Member

asturur commented Jul 21, 2021

@ShaMan123 does this seems a legit fix for you?

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jul 22, 2021

See this Originally posted by @ShaMan123 in #7220 (comment)

NO

Yes and no.
Yes it will fix the error but I am not sure why it is happening.
The logic assumes that the background/overlay color has been replaced by a Rect so it could be erased by the eraser.
That is where the true bug originates from.
I think I can reproduce now that I understand.

When I built the eraser mixin this specific logic was handled by the eraser but later on I moved it to Canvas.
This logic was correct when the eraser brush was in charge of replacing bg/overlay color to rects if they were erasable because it checked it every render.
Now it fails because it has no replacement mechanism.
I moved it because it seemed too expensive to run every mouse move and I stick to it.

If I am not mistaken this is where the bug comes from:

___setBgOverlay.call(this, property, value, loaded, callback);

__setSVGBgOverlayColor.call(this, markup, property, reviver);

So if my assumptions are correct the true fix would be to change the else blocks and add rects instead of filters/string values.
In addition, this proposed fix will only remove the error but it will not render the actual bg/overlay.

Therefore I think this is not a fix after all.

There is another bug regarding this block of code that I pushed into #7100 (which is waiting for your feedback):
The bg/overlay color should not be affected by canvas transform.

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jul 22, 2021

@chr314 Could you help me reproduce?
Did you load the canvas from JSON/SVG before this error happened?

@ShaMan123
Copy link
Contributor

I can't reproduce.
@chr314 are you setting bg/overlay color directly (assigning) or using the setBackgroundColor method as STATED in the instructions of the demo??

look at these 2 repos:
https://codesandbox.io/s/d16uq
https://codesandbox.io/s/dl79j

Read their comments to understand what they check

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jul 22, 2021

Yes and no.
Yes it will fix the error but I am not sure why it is happening.
The logic assumes that the background/overlay color has been replaced by a Rect so it could be erased by the eraser.
That is where the true bug originates from.
I think I can reproduce now that I understand.

When I built the eraser mixin this specific logic was handled by the eraser but later on I moved it to Canvas.
This logic was correct when the eraser brush was in charge of replacing bg/overlay color to rects if they were erasable because it checked it every render.
Now it fails because it has no replacement mechanism.
I moved it because it seemed too expensive to run every mouse move and I stick to it.

If I am not mistaken this is where the bug comes from:

___setBgOverlay.call(this, property, value, loaded, callback);

__setSVGBgOverlayColor.call(this, markup, property, reviver);

So if my assumptions are correct the true fix would be to change the else blocks and add rects instead of filters/string values.
In addition, this proposed fix will only remove the error but it will not render the actual bg/overlay.

Therefore I think this is not a fix after all.

There is another bug regarding this block of code that I pushed into #7100 (which is waiting for your feedback):
The bg/overlay color should not be affected by canvas transform.

After looking closely at serialization I can say confindently that the eraser mixin works as expected with no problems since serialization calls setBackgroundColor or setOverlayColor that the eraser mixin extends.

this['set' + fabric.util.string.capitalize(property, true)](value, function() {

@ShaMan123
Copy link
Contributor

ShaMan123 commented Jul 22, 2021

What I would do is add a warning here (or somewhere in the eraser, say at the beginning of the render cycle) instead explaining how to set bg/overlay color when using eraser and referencing the docs if bg/overlay color are not rects

@chr314
Copy link
Author

chr314 commented Jul 22, 2021

@ShaMan123 thanks
yeah I think I was using the bg color the wrong way

    //  this is WRONG!!
    canvas.backgroundColor = 'yellow';
    //  this is CORRECT!!
    canvas.setBackgroundColor('yellow');

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

Successfully merging this pull request may close these issues.

3 participants