NEW 139694
ContentEditable=True inside of an Iframe jumps to the top of the parent window. 
https://bugs.webkit.org/show_bug.cgi?id=139694
Summary ContentEditable=True inside of an Iframe jumps to the top of the parent window.
Michael Snyder
Reported 2014-12-16 12:29:52 PST
Steps to reproduce (easiest) 1) Create html page with two iframes (800px tall each) 2) In the lower iframe add another iframe with a page consisting of <div contenteditable="true" style="width: 100%; height: 500px;"></div> inside the frame 3) Open the page on an ipad and start typing in the contenteditable field 4) The page will jump to the top of the parent screen randomly when hitting certain keys and especially the space bar. TinyMCE will not work either. I have reproduced in Latest Chrome and Safari IOS. It appears there is a problem calculating the focus scrollTop.
Attachments
Testcase (353 bytes, text/html)
2017-06-02 17:52 PDT, Simon Fraser (smfr) 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
m.lewandowski
Comment 1 2017-03-14 05:52:38 PDT
Same thing affects CKEditor, which makes it hard to use on iOS.
Simon Fraser (smfr)
Comment 2 2017-06-02 11:43:11 PDT
Does this reproduce in iOS 10.3?
Cory LaViska
Comment 3 2017-06-02 13:42:07 PDT
I'm still seeing this behavior in the latest iOS. I actually discovered this while troubleshooting what I thought was a TinyMCE bug in Postleaf. It appears as though the frame's document.body.scrollTop value is always 0, regardless of whether or not the frame is scrolled. Then I realized you can't set an explicit height on an iframe in iOS. They seem to expand to the full height of their content. That said, I'm not sure if this is actually a Webkit bug or a side effect of iframe's on mobile Safari not accepting the height specified by CSS. It could be that TinyMCE, CKEditor, et al assume scrollTop will be a positive value when instead it stays at zero, and the libs are "fixing" the scroll position based on that value.
Simon Fraser (smfr)
Comment 4 2017-06-02 13:47:02 PDT
Thanks. It would be helpful to have a URL that points to a page that reproduces this for you, rather than me trying to create one from the instructions.
Simon Fraser (smfr)
Comment 5 2017-06-02 17:52:25 PDT
Created attachment 311892 [details] Testcase With this test case, I cannot reproduce the issue on an iPad running 10.3.
Jacek Bogdański
Comment 6 2018-08-08 03:40:15 PDT
The issue also exists on iOS 11.4. You can reproduce test steps using this codepen: https://codepen.io/jacekbogdanski/pen/NMbdwz Just scroll down and click "Type here" text.
Jacek Bogdański
Comment 7 2018-08-08 03:49:24 PDT
It also would be great to get some updates on the issue status thus it's pretty old and it's causing WYSIWYG editors based on iframes unusable.
Radar WebKit Bug Importer
Comment 8 2018-08-09 09:22:42 PDT
<rdar://problem/43097167>
Note You need to log in before you can comment on or make changes to this bug.