[Bug]: FixedLayout not respected after triggerLayout

[drinkspiller]

CheckList

• I agree to follow this project's Code of Conduct
• I have read and followed the Contributing Guide
• I have read and followed the Issue Tracker Guide
• I have searched and referenced existing issues and discussions
• I am filing a BUG report.
• I have managed to reproduce the bug after upgrading to the latest version
• I have created an accurate and minimal reproduction

Version

6.0.2

In What environments are you experiencing the problem?

Chrome

Node Version (if applicable)

None

Link To Reproduction

https://codepen.io/drinkspiller/pen/QWXoYzr?editors=0010

Steps To Reproduce

1. Create a Group with a defined width and height (e.g. width: 100, height: 100) and configure it to use FixedLayout.
2. Add a child to the Group that is wider than the Group's initial size (e.g. width: 500, height: 25);

Expected Behavior

The FixedLayout docs note that when using this LayoutStrategy, "Layout will keep target’s initial size."

I expected the group to remain 100x100 and for its wider child to extend beyond the group's bound similar to CSS' overflow: visible, along the lines of this html/css example

Actual Behavior

1. Without calling triggerLayout, the child does extend beyond the parent, but only a little bit — the full width of the child is not displayed (demo)
2. If triggerLayout() is called, the Group, which was initialized with FixedLayout, seems to act as if it has reverted to FitContentLayout (demo) (note the group's height is no longer the initial value of 100)

Error Message & Stack Trace

No response

[drinkspiller]

Once the group is initialized with a fixed layout, adding new objects won't change the group's size and therefore also its position.

• src/LayoutManager/README.md

[zhe-he]

FixedLayout only guarantees the initial size, and the size can be actively updated later through trigger. I don't know if this is intentional.
According to your requirements, you can customize the layout method. The following two layouts can meet your needs. Please use version 6.4.0 or above.

import { LayoutStrategy, classRegistry } from "fabric";

export class FixedLayoutA extends LayoutStrategy {
    static readonly type = "fixed-a";
    shouldPerformLayout() {
        return false;
    }
}

classRegistry.setClass(FixedLayoutA);

import type { FabricObject, StrictLayoutContext } from "fabric";
import { LayoutStrategy, Point, classRegistry } from "fabric";

const LAYOUT_TYPE_IMPERATIVE = "imperative";

export class FixedLayoutB extends LayoutStrategy {
    static readonly type = "fixed-b";
    calcBoundingBox(_: FabricObject[], context: StrictLayoutContext) {
        if (context.type === LAYOUT_TYPE_IMPERATIVE && context.overrides) return context.overrides;
        const { width, height } = context.target;
        const center = context.target.getRelativeCenterPoint();
        const size = new Point(width, height);
        return { center, size };
    }
}

classRegistry.setClass(FixedLayoutB);

[asturur]

Fixed Layout should have group width and height property win over children size. That is what i remember.
There could be a bug.
The fact that the object extends a bit outside the border is a caching issue, is not supposed to extend at all, but i m not sure all the proper tests have been done in that area.

[drinkspiller]

Thank you both, for your replies! @zhe-he , the FixedLayoutA solution you provided (coupled with disabling objectCaching) produced the expected results:
https://codepen.io/drinkspiller/pen/NWZVYMz

The FixedLayoutB approach did not — even though the Group's width and height log as 100x100, the background does not render: https://codepen.io/drinkspiller/pen/bGPyvKM

Is FixedLayoutB set up as you intended?

As @asturur noted, I expected fixed Layout to have the group width and height property win over children size.

[zhe-he]

@drinkspiller
I'm sorry for only seeing the above message now. Regarding the bug in layout B, this is the fixed version, and the previous code has been updated.

https://codepen.io/zhe-he-the-vuer/pen/YzmZzaB

[asturur]

I didn't have time to look at this issue, to me it make still think of a bug

[drinkspiller]

@drinkspiller I'm sorry for only seeing the above message now. Regarding the bug in layout B, this is the fixed version, and the previous code has been updated.

https://codepen.io/zhe-he-the-vuer/pen/YzmZzaB

Thank you!

[asturur]

This needs to be fixed in the core library anyway