Fabric.js: Hiddentextarea auto scroll the page

[keanass]

Hiddentextarea is scrolling the webpage when double click it to modify the text content in latest version of fabric, it maded for ios to show the keyboard but that takes effect also in computer browsers.

[keanass]

i think you must keep it like that with position fixed and do not focus it :

<textarea autocapitalize="off" style="position: fixed; bottom: 20px; left: 0px; opacity: 0; width: 0px; height: 0px; z-index: -999;"></textarea>

[asturur]

HiddenTextarea must move around the itext object to serve composition purposes.
If it is not focused, most of the events do not fire.
What is the problem of the page scrolling on textbox when editing? Can you share a particular setup where this hurts?

[keanass]

this.initHiddenTextarea(e);
this.hiddenTextarea.focus();

if the canvas size is big and double click on a textbox to edit it it, the whole page is getting scrolled to position of this textbox.

[asturur]

please make a demo on 1.6.1
On Apr 29, 2016 12:14 PM, "keanass" [email protected] wrote:

this.initHiddenTextarea(e);
this.hiddenTextarea.focus();

if the canvas size is big and double click on a textbox to edit it it, the
whole page is getting scrolled to position of this textbox.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/kangax/fabric.js/issues/2904#issuecomment-215677260

[netray]

I believe I have the same issue.

This is the demo:
https://jsfiddle.net/m9bweyc4/2/

Usecase:
FullHD canvas element is inserted into a smaller wrapper and scaled using CSS to fit that container / screen, thanks to this the end result is always full hd, events are scaled nicely using .getPointer method.
The only thing that ignores scaling is the hidden textarea that takes the coordinates from the canvas itself and causes the whole page to scroll.

Hope it helps.

[asturur]

I will see if with the logic of getPointer we can also move the textArea better.
But that this css scaling is not a good idea in my opinion. You pay the performace load of a full size but work in small size, while you could work in small size and get the bigone when going to dataURL({multiplier: 10});

@keanass can you please also make a demo to check if the issue is the same?

[danivallucas]

The webpage scrolls also in a canvas with zoom < 1 (Chrome).

Add a 600x400 canvas.
Then set canvas zoom to 0.5 and add an IText at left=800 and top=700, for example, so it will be next the right bottom corner.
When enter editing the page will scroll because fabric will try to manipulate hiddenTextArea at point (1600, 1400) I guess.
My screen resolution is 1366x768.

Workaround: I changed initHiddenTextarea and _updateTextarea considering zoom at "p" point:

        p.x *= canvas.getZoom();
        p.y *= canvas.getZoom();

[raffareis]

this is really annoying, had to solve this by setting p.x=0 on initHiddenTextarea and _updateTextarea.

[stephenmudra]

I'm seeing a similar issue, can be seen on http://fabricjs.com/kitchensink as well.

If you add a long enough single text line it pushes the page over when it reaches the browser window.
In my use case as I was centring the canvas the issue was visible as soon as the textarea left the canvas boundaries.

The work around I added was preventing the textarea from positioning itself outside of the canvas, which seemed to work for my use case. However I'm not using zoom or css resizing.

[asturur]

for sure canvas zooming is something to solve. for the css i do not know if i can help somehow. Maybe we should have a paramerer to have it fixed(no mobile support) and repositioning (issues with big pages and css)

[jfbloom22]

Adding this css worked well for me:
textarea[data-fabric-hiddentextarea]{ position: fixed !important; }

opinion: Unless the project is built entirely on fabricjs, then a lot of projects will already have a solution inlace to zoom to the input or create space for the on screen keyboard. Thus, it seems to me this feature should either not be a part of fabricjs, or there should be an easy option to disable it. In my use case, disabling this feature worked better on iOS and the desktop browser.

[asturur]

i added a special attribute to the textarea to allow people to interact with it in some way.
Not sure if it helps