fix(textarea): ensure the position of hiddenTextarea stay within the boundaries…

[zhang759740844]

Description

hey, I am using the textarea to show a long article with some annotation. And I found if I want to enter new lines at the end of the textarea whose parent element is overflow hidden, the position of hiddenTextarea will exceed the boundaries of document. And it make whole element shift up.

It seems to be similar to issue #9886, but he does't replicate the bug, so I make a example
https://jsfiddle.net/zacharyzch/L4sy3gu1/134/

here's the screenshot:

Jun-26-2024.16-35-18.mp4

In Action

• In _calcTextareaPosition, add a additional check at last, to check the position of hiddenTextarea
• remove the default border and marginbottom of the hiddenTextarea，to make the height of hiddenTextarea is equal to charHeight

and here’s the improved result：

new2.mp4

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[asturur]

how this doc.body.clientHeight - charHeight relates to maxHeight = upperCanvasHeight - charHeight that we check up before, and why we can't have a single max vertical limit and use that?

[asturur]

https://github.com/fabricjs/fabric.js/pull/9948/files#diff-355c433500e45e82cda2cb4339613f1dacbb1d6ef43d8b0b98bf8fd293712976R588

[zhang759740844]

The maxHeight ensures that the position of the hiddenTextArea does not exceed the bounds of the canvas, which means the calculated absolute coordinates are relative to the canvas's position. However, our hiddenTextarea is appended to the document.body, and there's no problem as long as the canvas stays within the viewport. But if the canvas extends beyond the viewport, the absolutely positioned hiddenTextarea would exceed the viewport, causing the browser to shift all elements upward to ensure hiddenTextArea is visible on screen. So I add a final check to ensure the calcualted absolute coordinates not exceed the viewport.

[zhang759740844]

The image on the left shows the scenario where maxHeight is effective, with hiddenTextarea displayed within the canvas boundary. The image on the right illustrates the situation where the canvas extends beyond the viewport; the hiddenTextarea meets the maxHeight condition, but it exceeds the range of the viewport, causing the browser to shift all elements upwards to ensure the hiddenTextArea is visible on the screen.

[zhang759740844]

Additionally, in my view, maxHeight should actually be expressed as maxCanvasHeight, then the canvas offset is added to obtain the true position:p.y += this.canvas._offset.top;. Therefore, I didn't use the same maxHeight to make the judgment, but instead added another check afterward to ensure thatthe existing logic is not affected.

[asturur]

i also see the bad behaviour of the fiddle, but i would see it reproduced in a normal page to discuss it better. Maybe i can add a simple test case in the sandboxes of the repo

[zhang759740844]

I understand the move page up issue. What i do not understand is if the textarea is below the fold and you don't move the page up, i tried your fiddle in a number of ways. There are 2 issues here, one is that the page scrolls and one is that it scrolls also when the text is completely outside the canvas so it scrolls in the white.

Now i do think the textarea should follow the position until is on the html canvas element and make the page scroll, but scrolling where the canvas is not available is useless.

I can see how the scrolling part is more an app behaviour that is subject to opinions rather than a real bug - non bug.

This should be configurable in some way, but i m not certain i want to add it as a configurable options, maybe if there is a way to pass in some kind of limits for the textbox placement.

I'm not sure if I understand correctly. Do you mean you want me to scroll the canvas up when the textarea is about to go below the fold?

[zhang759740844]

i also see the bad behaviour of the fiddle, but i would see it reproduced in a normal page to discuss it better. Maybe i can add a simple test case in the sandboxes of the repo

Thank you very much. I also hope to resolve this issue better and contribute a little to this project. ^_^

[asturur]

Sorry i wrote my message in a confusing way.
Let me start a couple of files to discuss this better

[zhang759740844]

No problem at all, and I'll dive deeper into the source code as well. I'm looking forward to discussing this further.

[asturur]

I didn't forget about this, i have been doing other stuff

[mhieupham1]

i think the issue in your css styles, not fabricjs bug, why it scroll when a new line is added, it is for touchscreen devices use virtual keyboard

[zhang759740844]

i think the issue in your css styles, not fabricjs bug, why it scroll when a new line is added, it is for touchscreen devices use virtual keyboard

I don't think it's a CSS issue. Setting the outermost div to overflow:hidden is a common practice. Moreover, the same problem exists on mobile devices as well.

[asturur]

Sorry for not coming back yet

[zhang759740844]

Is there any movement on this? ToT

[asturur]

No but as you see is top of the list of the PRs.
The issue with this PR is that testing is a mess.
I need to setup usecases where the logic can be tried

[lecramr]

I think I also encountered this bug now in real world, to be print conform I have a pretty large canvas, and scale it down for the user to view it better via css transform scale and now this also happens to me.

[asturur]

This needs to be fixed and tested properly.
What blocks me to do so is that i need so many test cases and devices to do so is an enormous amount of time.
I need the test cases first of all. I would appreciate if someone could build a bunch of html layouts that we can keep around to test those cases.
We need to consider with scrolling, without scrolling, in a modal style div, in a scrolled page.

I usually add a file in the testcases folder, but in this case we need to change the html layout and i don't have a quick way to do that

[YoniZiv]

Not sure if it's related, but I'm experiencing something that might be related.
I have a fabric editor that's wrapped with a zoom container that I created (the container adjusts the content to fit 16:9 or 9:16 then sets the container's scale (using transform)
Whenever I have a textfield at the bottom of the page and I edit it "enlarges" the container and adds whitespace that shouldn't be there.
I monitored the event with the performance tab and it seems that the initHiddenTextArea calls updateTextareaPosition and I guess that's what's causing the shift

[zhang759740844]

Not sure if it's related, but I'm experiencing something that might be related. I have a fabric editor that's wrapped with a zoom container that I created (the container adjusts the content to fit 16:9 or 9:16 then sets the container's scale (using transform) Whenever I have a textfield at the bottom of the page and I edit it "enlarges" the container and adds whitespace that shouldn't be there. I monitored the event with the performance tab and it seems that the initHiddenTextArea calls updateTextareaPosition and I guess that's what's causing the shift

It seems like the same issue.
Since this PR hasn't been merged, you might try resolving it with the following trick.
You need to check the source code of the fabric version you are using firstly. In my version, updateTextareaPosition calls _calcTextareaPosition. And in this method, it will calculate the position of hiddenTextarea

You can create a subclass of a Textbox and then override the _calcTextareaPosition method. Add the code inside the red box to the original method to ensure the hiddenTextArea doesn't exceed the screen.

Use this subclass to replace the Textbox

And there are some style adjustments as well, but see if you can roughly solve your problem first.

[zhang759740844]

This needs to be fixed and tested properly. What blocks me to do so is that i need so many test cases and devices to do so is an enormous amount of time. I need the test cases first of all. I would appreciate if someone could build a bunch of html layouts that we can keep around to test those cases. We need to consider with scrolling, without scrolling, in a modal style div, in a scrolled page.

I usually add a file in the testcases folder, but in this case we need to change the html layout and i don't have a quick way to do that

Sorry, I missed this message. I can help you,but I don't know how to work together with you