Bug 5911 – REGRESSION: Page scroll position jumps when clicking on word in editable div

• Component: HTML Editing
• Status: RESOLVED FIXED

[Dan Wood]

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.

[Dan Wood]

Created attachment 4899 [details]
Reduced Test Case: HTML, stylesheets, javascript needed to reproduce

[Alexey Proskuryakov]

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>

[Adele Peterson]

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.

[Adele Peterson]

<rdar://problem/4363794> REGRESSION: Page scroll position jumps when clicking on word in editable 
div (5911)

[Adele Peterson]

I have a TOT fix for this in my tree- but I'm still working out a few kinks.

[Adele Peterson]

Created attachment 5198 [details]
patch

[Darin Adler]

Comment on attachment 5198 [details]
patch

Nice simplification, too. Looks great. r=me