Steps: * Take the attached reduced test case, and open in a TOT browser with the window short enough to have a vertical scrollbar. * Click (or double-click) on a word somewhere in the body text (which is marked as contentEditable) What should happen: * You should enter editing mode without having the scroll position jump. Very disconcerting, especially if it was a double-click and you expected to select a word!) What actually happens: * Scroll position jumps so that the top of the editable div is at the top of the webview. Analysis: Somebody was probably trying to be helpful by maximizing the amount of text you can see when you begin editing. But the jump is annoying, and more confusing. The scroll jump does not happen when you are scrolled way down in the text and the entire webview is filled with the editable div.
Created attachment 4899 [details] Reduced Test Case: HTML, stylesheets, javascript needed to reproduce
Bumping priority to P1 (regression from the latest released version). Goes via this code path: <http://www.opendarwin.org/pipermail/webkit-changes/2005-October/ 001356.html>
I'll take this one. Right now the scrolling code is getting triggered by setFocusNode when you click on the div. I think we need to move the call to scrollRectToVisible so we can be more precise about what kind of scrolling behavior we want depending on what caused the node to be focused.
<rdar://problem/4363794> REGRESSION: Page scroll position jumps when clicking on word in editable div (5911)
I have a TOT fix for this in my tree- but I'm still working out a few kinks.
Created attachment 5198 [details] patch
Comment on attachment 5198 [details] patch Nice simplification, too. Looks great. r=me