Textbox selection is still visible outside of the clipPath

[drinkspiller]

Textbox selection is still visible outside of the clipPath:

Originally posted by @drinkspiller in #10269 (comment)

[drinkspiller]

Note: In addition to the selection, the cursor also appears outside of the clipped area:

[asturur]

Thanks for opening the issue.
This is a bit of a complicated issue, what do you think is the use case of this? can you explain it a bit?
Why would you like to be able to edit text but have no idea where cursor/selections are?

Because when we bake a behavior in the library we need to make sure it is at least supported by common sense

[drinkspiller]

Thanks, @asturur , I appreciate your reply.

That demo essentially replicates what in HTML would be a div with overflow: hidden. The expected behavior is that anything outside of the area is hidden, including cursor or selected text. (demo)

Likewise, a clipPath defines the area inside of which contents are visible. Common sense is that when an object specifies a clipPath defining the area in which content is visible, that content outside that is not visible.

[drinkspiller]

From the other perspective, what is the justification for "a clipPath defines the area in which things are visible, but sometimes things (e.g. selection, cursor) are actually still visible outside the clipped area"?

[asturur]

I wasn't debating the logic itself of clipping.
I was just thinking who wants to edit text in a clipped container.
I understand from a pure concept of the api it make sense that what is clipped is not visible.

I m trying to understand how important it is to get fixed.

[drinkspiller]

Thank you, Andreas. 🙏 For me, it's critical to what I'm building. I'd be happy to contribute to a fix however I'd need ample guidance.

…

On Fri, Nov 15, 2024, 10:30 AM Andrea Bogazzi ***@***.***> wrote: I wasn't debating the logic itself of clipping. I was just thinking who wants to edit text in a clipped container. I understand from a pure concept of the api it make sense that what is clipped is not visible. I m trying to understand how important it is to get fixed. — Reply to this email directly, view it on GitHub <#10274 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQXCXBVL6XFRICF7ZRETL2AYVRXAVCNFSM6AAAAABRZZMJE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZZGUZDCMJTHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[drinkspiller]

In version 6.5.2, the rendered selection for selected text (the blue background behind selected text) in an IText or Texbox instance is no longer rendered at all if the IText/Textbox is nested within a group that has a clipPath applied.

Demo using 6.5.2 (no visible selection for selected text)"

Demo (same code) using 6.5.1 (visible selection for selected text):

[asturur]

Thank you for pinpoitning the version that broke.

https://github.com/fabricjs/fabric.js/releases/tag/v652

I don't see any possible culprit in the list of changes, i would have argued that 6.5.0 was a good candidate to break this.

I'll check the diffs asap, maybe some of my TS-cleaning-only changes i actually broke something

[asturur]

Weirdly is the render loop that breaks it.

[drinkspiller]

That is very unexpected

[asturur]

With 6.5.1 and the long standing cache invalidation bug every render loop we were rendering everything from scratch.

6.5.1:

With the bug fixed in 6.5.2 the caching ( that while disabled by you is forced on because the clipPath ) is skipping the text render in the loop, and nothing is calling the renderSelection again

When the text object is outside the group that is not a big deal because the render method of the object is taking care of selection also when cached.

Once the the text selection is drawn it marks the top context as dirty and gets cleared at the next render.
There are multiple issues with a recurring animation ( yours ) and the one triggered by the cursor, you can see that the cursor in your case is glitching

[asturur]

i think the only solution for the short term is for you to have this loop here:

  function renderLoop() {
    canvas.renderAll();
    const active = canvas.getActiveObject();
    if (active && active.renderCursorOrSelection) {
      active.renderCursorOrSelection();
    }
    fabric.util.requestAnimFrame(() => {
      renderLoop();
    });
  }

In order to fix this i have too coordinate a change in the function renderTop and make the text functions able to call that.
The is is doing this without over clearing or over rendering, so it requires a bit of thinkering for now.

Imho the performance improvement of 6.5.2 is worth the upgrade for the hassle of adding explicits renderCursorOrSelection when you need forced loops or animations.