Fabric.js: Starting IText inline editing scrolls to top of the page

[ralfwahl]

When I click inside an IText field to start the inline editing, the whole document scrolls up to the start of the page, which is quite confusing for the user. I have this effect with fabric.js 1.4.4 and 1.4.5. It can be also seen in the official IText demo http://fabricjs.com/test/misc/itext.html:
Take one of the last IText objects, e.g. "Lots of text (performance test)" and click there. The page will jump up, making the current inline editing move out of the visible screen.

This problem can be watched for example with Firefox 28/29 and Internet Explorer 11. Chrome 34 handles it better, stays at the current document scroll position.

When trying to debug the script, it seems that all the event handling starting from _onMouseUp works as expected. After leaving that fabric.js code some rerendering takes place that moves the document upward.

Another effect is, that it works OK if I'm in fullscreen mode of one scrollable DIV containing the canvas (not the F11 overall fullscreen, just of the DIV node). In that case everything stays at place. Is there something happening on top of the document that makes some browsers scroll to that position?

Kind regards
Ralf

[somecodemonkey]

Its because there is an focus call on the hidden text area for an itext object.

[ralfwahl]

Yes, you are right. Thank you for that information! Since the focus() call seems to be needed for the text input to work, I changed fabric.IText.prototype.initHiddenTextarea locally as a prove for that idea:

So far the text area is added to the document's body:
fabric.document.body.appendChild(this.hiddenTextarea);

When I use something like the following, the calling of focus() lets the document scroll positiion where it is:
if (this.canvas && this.canvas.upperCanvasEl) {
this.canvas.upperCanvasEl.appendChild(this.hiddenTextarea);
} else {
// fallback with old code, since I'm not sure if upperCanvasEl is always available
// when calling the function
fabric.document.body.appendChild(this.hiddenTextarea);
}

So adding the text area there works better with Firefox and IE, even when the CSS style stays at "position: absolute; top: 0; left: -9999px".

What do you think: Could this be a valid solution to the problem, or is there a reason for the text area being added somewhere else to the document?

Kind regards
Ralf

[sgrigson]

I'm also running into this issue in Chrome. Any resolution planned?

[sgrigson]

Here's a fix I added that seemed to resolve the issue:

In initHiddenTextArea I changed this
this.hiddenTextarea.style.cssText = 'position: absolute; top: 0; left: -9999px';

to this

this.hiddenTextarea.style.cssText = 'position: fixed; top: 0; left: -9999px';

It no longer changes the scroll position in the document when typing into an IText field.

Hope this helps!

[somecodemonkey]

You could try setting the the hidden textarea to the same top value relative to the itext object on the page although i havent tested it in a while so not sure how well it works.

[Kienz]

@sgrigson Looks good - I've tested it on Windows with FF 30, Chrome 35, Safari 5.1 and IE 9.
Maybe someone can test it on iPad / Android Tablet.
If the tests look good can you create PR.

Thanks!

[sgrigson]

I tried to create a PR, but didn't have access to create a branch.

Also, this works for vertical position, but if you're located far to the right on the canvas and have scrolling to the left, the same problem will happen where you get set to the left canvas (probably the -9999px position). Still, vertical scrolling handles the biggest use case.

[radykal]

@sgrigson This is not a good solution for mobile devices. The window still goes up.
@ralfwahl I tried that solution and its working, except on chrome. If you hit the backspace button, chrome will go back in the browser history.

[sgrigson]

@radykal Well, in that case mobile devices work exactly the way that this works now on every other device. At least it's not /more/ broken on mobile.

My use case didn't require this working for mobile, but thanks for cross-checking that.

[ralfwahl]

We are using the solution I proposed now for some weeks. Generally, it works: No more scrolling to top of the page.

@radykal With Chrome V35 on Windows now I _sometimes_ have problems with the page jumping up using original Fabric.js on http://fabricjs.com/test/misc/itext.html. Don't know when or when not this happens, it seems to be rather seldom. With my patch I never had that page jumping so far. In both cases backspace button doesn't trigger going back in the browser history on my system (Windows 8, Chrome 35).

Regarding mobile devices, I now tested it with a Android smart phone, using Chrome. Both original and my version behave the same: no scrolling to top of page, on-screen keyboard shows up, but entering any characters there doesn't put the text into the IText. As far as I can tell, this generally doesn't seem to work on that platform. Maybe that's a reason to open another issue like "Onscreen keyboard doesn't enter text into IText on Android Chrome"? The patch discussed doesn't seem to change the mobile handling on my device
@radykal What kind of mobile are you refering to? Android, too?

[somecodemonkey]

Chrome on android doesnt support the keypress event which is why itext doesnt work.

[radykal]

@ralfwahl No I just test it on Mac. But i now test it in the online version of my application and there I dont have that kind of bug. On my local server I have it. Will do some testing. Thanks anyway for your solution. I am also using it.

[nsanden]

Any new developments on this? Using chrome and seeing the same thing.

[inkubux]

I'm having the same issue with chrome.

[nsanden]

@inkubux this worked for me https://github.com/kangax/fabric.js/issues/1310#issuecomment-47124568

[asturur]

I was investigating.
The chrome "JUMP" happens always.
May it be a big or a small JUMP it looks like a browser problem.
For me best solution is to have :

this.hiddenTextarea.style.cssText = 'position: fixed; top: 0px; left: 0px; opacity: 0; width: 0px; height: 0px; z-index: -999;';

With any top value i get , even trying to mimic the iText one ( canvas.top and iText.top ) Chrome JUMPS a little bit. This happens just if you are on high zoom level ( ctrl +, to the max ).
if you scroll to the right and have left -9999 it jumps again.

Anyone willing to test this css setup?

i also tried to use

var rect = this.canvas.wrapperEl.getBoundingClientRect()

to get good position.

[asturur]

Edit:
I'm getting NO JUMPS at all with this config:

this.hiddenTextarea.style.cssText = 'position: fixed; bottom: 20px; left: 0px; opacity: 0; width: 0px; height: 0px; z-index: -999;';

[danharper]

@asturur That seems to have fixed it for me, thanks!

[Pakku]

@asturur Worked for me too. Thanks :) It was a headache

[asturur]

At the end we didn't fix this? i cannot find a pr.

[filiperoberto]

It's still scrolling for me, but now to bottom. It's weird because some times textarea is appended to body and sometimes to canvas-container. When it's appended to body there is no problem, but to canvas-container it scrolls to bottom.

[HunterMitchell]

@filiperoberto @asturur I can also confirm in my configuration, the text JUMPS to the bottom of the page. I was able to fix it by applying position:fixed !important; top:0 !important; in my css to all textboxes.

[asturur]

in the current configuration the textbox is placed wher you clicked and then follow the cursor. How are you entering the textedit? clicking or by code?

[HunterMitchell]

Clicking. I have an event that places the text box.

On Monday, June 6, 2016, Andrea Bogazzi [email protected] wrote:

in the current configuration the textbox is placed wher you clicked and
then follow the cursor. How are you entering the textedit? clicking or by
code?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kangax/fabric.js/issues/1310#issuecomment-223892747,
or mute the thread
https://github.com/notifications/unsubscribe/AGlOWISiBmudqBlHGLSojtnuUQqf7Hrrks5qI9R2gaJpZM4B38rU
.

[murilobd]

@filiperoberto I was with this same issue and fixed with that:

var bodyRect = document.body.getBoundingClientRect(),
        elemRect = this.canvas.upperCanvasEl.getBoundingClientRect(),
        offsetRect = elemRect.top - bodyRect.top;
this.hiddenTextarea.style.cssText = 'position: fixed !important; top: ' + offsetRect + 'px !important; left: 0px; opacity: 0; width: 0px; height: 0px; z-index: -999;';