Demo Site: Scrolling down and clicking into Textarea jumps viewport to top. about draft-js

[teod]

I still can reproduce this issue using Google Chrome Canary Version 61.0.3154.0

[meirkoen]

Make sure you have the following css setting:

html{
height: 100%;
}

If not, the value of window.document.documentElement.clientHeight will be the same as the value of window.document.documentElement.scrollHeight and this is the cause of this bug.

[thoughtpalette]

Hmmm. Just tested on an incognito tab with no add-ons and I still have the same behavior.

I'm not able to reproduce this behavior on an FB comment input.

I do however receive some react based console errors/warnings. Probably unrelated.

Here's the behavior in an incognito window. Happens whether or not the textarea has focus.

[hellendag]

Thanks all, this is really helpful.

I'm fairly sure this is related to scroll management during focus, here: https://github.com/facebook/draft-js/blob/master/src/component/base/DraftEditor.react.js#L328

[Prinzhorn]

I'm on Ubuntu and I'm seeing the same on Chromium 53.0.2785.143 but not on Chrome 54.0.2840.90

Chromium

Chrome

Two things:

1. Why on earth does Chromium behave different from Chrome?
2. UA sniffing is bad and you should feel bad. Removing the "isWebkit" hack fixes it in Chromium.

It's also not just when clicking the editable area, but every time you type below the fold. The scrolling alternates between top and bottom.

Here you see me doing nothing but smashing the ENTER key.

The problem is fixed for me on Chrome Version 56.0.2924.87 (64-bit) but comes back if chrome://flags Experimental Web Platform features is turned on.

Don't know if that is an issue or not?

[yujiangshui]

I got the same problem using Google Chrome Canary Version 62.0.3174.0 (Official Build) Canary (64-bit), but it works fine in Google Chrome Version 59.0.3071.115 (Official Build) (64-bit) and Safari.

And some of my customers feedback they have this problem. We need to reopen this issue @tylercraft

[sophiebits]

The bug in Chrome 61 should be fixed if you update your node modules to include fbjs 0.8.15 (just released) as Draft's dependency.

[sophiebits]

yarn upgrade fbjs should do the trick. Otherwise yarn is going to reuse the existing lockfile.

[hellendag]

Weird. Are you using any browser plugins or extensions?

[thoughtpalette]

Just Privacy Badger. Though the behavior is reproducible with or without it enabled. :|

[hellendag]

I don't think I've seen this, and we can't repro it here. Do you see the same issue when focusing a comment input on www.facebook.com?

[tjisousa]

I'm using the exact same Chrome version as you and I can't reproduce this.

Seeing similar issues in Safari Mac on the Draft.js site.

1. Zoom in on text box (with pinch&zoom, not text size)
2. click somewhere to position to the cursor.

Result: Even though the textbox is completely in view, the viewport jumps to left: 0 and some top: 0+scroll(?) offset.

The window size can affect if you can scroll. So depending on if you've scrolled (unzoomed) or not, you might be jumped to the top-left or some lower position based on the scroll..

[knowbody]

works fine for me on Chrome Version 48.0.2564.109 (64-bit) / El Capitan 10.11.3

[jamesbrewerdev]

I'm able to reproduce in Chrome Incognito Version 48.0.2564.103 (64-bit) on OS X El Capitan Version 10.11.1.

Maybe an El Capitan problem? I've noticed a lot of problems with various projects/programs/things since upgrading.

[hellendag]

I can repro the jump in Safari described by @JaRail with pinch+zoom. Not sure if it's the same issue, but still worth investigating.

Still can't repro the original issue in Chrome. I'm also on El Capitan 10.11.3.

Also repros in the FB feed!

This is a bigger problem than we may have thought. With pinch & zoom in safari on mac, I am getting some jumping in the main FB feed.

1. Zoom in on post in your feed
2. Click comment box

Result: View is positioned to left:0. Vertical position remains unchanged.
Expected: No change in viewport position

Can also repro FB feed issue with Chrome on mac, same steps as Safari. I could not repro in Firefox Dev Edition as it doesn't seem to support pinch & zoom o_O

[bloodyowl]

Tracked down the reason why it fails, and this comes down to fbjs.

https://github.com/facebook/fbjs/blob/3df1c679208d405b5996fee684c9527a034e2f01/src/core/dom/getScrollPosition.js#L31-L34

What occurs when window is the scrollParent in a webkit browser is that document.body is used for the measurements, where document.documentElement is the right element to check:

https://github.com/facebook/fbjs/blob/3df1c679208d405b5996fee684c9527a034e2f01/src/core/dom/getDocumentScrollElement.js#L15-L17

This results in an incorrect scroll position:

[bloodyowl]

just tested, and focus has the expected behaviour in chrome when the isWebkit condition is removed. https://github.com/facebook/fbjs/blob/3df1c679208d405b5996fee684c9527a034e2f01/src/core/dom/getDocumentScrollElement.js#L30

[AlastairTaft]

I get this issue on chrome\MAC. To get around it for now I'm using my own version of focus that calls the getUnboundedScrollPosition instead of getScrollPosition.

I can see that the problem area seems to be the following lines.

(Passing in `window` to the function)

At this point you can see that the value of yMax is going to be 0 which means the value passed back will always be `y: 0`

Something's not right here but I don't think it's using the correct element for viewport. The document.documentElement is the <html /> element when I think what it should be using here is the <body /> element. Else the clientHeight will always be the same as the scrollHeight.

Created a pull request here.

[victorhaggqvist]

Can reproduce with ArchLinux Chrome Version 51.0.2687.0 dev (64-bit), but it works with Chromium Version 49.0.2623.110 (64-bit).
Tested on https://facebook.github.io/draft-js/ which atm claims Draft v0.3.0, ReactDOM v0.14.7, React v0.14.7.
Tested on the thing i was working on as well, Draft v0.3.0, ReactDOM v15.0.0-rc.2, React v15.0.0-rc.2, with the same result.

EDIT: Can reproduce Chromium Version 49.0.2623.110 (64-bit) with no extensions (which may or may not be related to React devtools?).

[devhero]

@hellendag it's still broken on Chrome 51.0.2704.84 (64-bit) on OSX El Capitan.

[alexeygolev]

It's works ok for me in Chrome 51.0.2704.84 on OSX El Capitan... weird

[devhero]

@alexeygolev sorry, I made a mistake. the official draft-js page works correctly, even the examples. Instead, using it with my bundled libraries, even in a polished page, the issue still appear. IMHO it's a combination of libraries but it's complicated to find the match.

[kalaxiya]

Works correctly in production. But if develop in a "localhost://" it happens.

[appsforartists]

Seeing it in both these editors:

https://facebook.github.io/draft-js/
https://www.draft-js-plugins.com/

On a Chromebook running version 51.0.2704.106. Thankfully not seeing it on Facebook.com, though I've certainly seen plenty of scroll management bugs there in the past.

[tylercraft]

I'm not able to duplicate with Chrome 54.0.2840.59 or Safari 10.0 (12602.1.50.0.10) on either of these pages:

https://facebook.github.io/draft-js/
https://www.draft-js-plugins.com/

Therefore I'm going to close this out.

[dtipson]

This might have to do with the change to ref: it's now recommended to be a function that sets a context value instead of a string.

[optimatex]

I got the same problem. But for my case disabling Experimental Web Platform features solved the problem.
However, I still worry about this potential issue in some browser version

[sophiebits]

(If you do a hard reload on draftjs.org and try again, it should be fixed there.)

[teod]

@sophiebits I tried to include [email protected] in my modules, still experiencing this issue.

EDIT: It didn't worked for me using yarn, npm install did the thing, anyway imho is still faulty, maybe draft.js dependencies should be updated ?

[markpradhan]

Enter is still broken in chrome 61 (stable release cycle), it scrolls to center of editor. As is editorEl.focus() (scrolls to top). Just noticed today.

EDIT: removed node_modules and yarn.lock and hit yarn -> fixed
just yarn upgrade fbjs didnt do anything for me though

[tuan072090]

This error happen when I upgrade to v0.10.1, just downgrade to v0.10.0 and everything work fine :D

[fabdrol]

I've seen this issue on regular text fields as well - in two different React apps - without any scroll listeners anywhere on the page. Not sure if it happens in non-React apps too; but disabling Experimental Web Features solves the problem for me. Might be a side effect of a Chrome bug?