Bug 68322 - Chrome resets the textarea scroll bar (scrollTop) when focus() is called
Summary: Chrome resets the textarea scroll bar (scrollTop) when focus() is called
Status: RESOLVED DUPLICATE of bug 15695
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-18 01:14 PDT by Mike West
Modified: 2014-05-01 09:03 PDT (History)
3 users (show)

See Also:

Attachments
The original attachment from the Chromium bug that demonstrates the issue. (114.02 KB, text/html)
2011-09-18 01:15 PDT, Mike West 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mike West 2011-09-18 01:14:23 PDT 
Originally reported as http://crbug.com/75072

Verified against WebKit ToT this morning.

---

Chrome Version       : 11.0.672.2
URLs (if applicable) :
Other browsers tested:
  Firefox 3.x: Firefox 3.6.15pre OK

What steps will reproduce the problem?
1. Open the attached page with the console enabled.

What is the expected result?

Focusing programmatically has no effect on the scroll position, so the "Before focus" and "After focus" values are the same.

What happens instead?

scrollTop is reset to 0, which is shown as "After focus"

As noted, this behaves as expected in Firefox.
Comment 1 Mike West 2011-09-18 01:15:09 PDT 
Created attachment 107787 [details]
The original attachment from the Chromium bug that demonstrates the issue.
Comment 2 Alexey Proskuryakov 2011-09-19 10:18:32 PDT 
We still track this as an open bug for some reason, but this is intentional behavior.

*** This bug has been marked as a duplicate of bug 15695 ***
Comment 3 Matthew Flaschen 2011-09-19 13:12:43 PDT 
This doesn't seem like a duplicate of 15695 to me.  That is about the caret (input cursor), while this is about scrollTop.  

Focusing has no effect on scrollTop in Firefox (as stated in my original report) or IE 8 (just tested).
Comment 4 Jamison Gray 2012-10-09 17:26:35 PDT 
I agree with the last commenter that this is NOT a duplicate of 15695; would it be possible to reopen this bug?
Comment 5 Matthew Flaschen 2012-12-25 14:56:35 PST 
This is still present in Chromium 22.0.1229.94, and is not a duplicate of bug 15695.
Comment 6 Daniel Trebbien 2014-05-01 09:03:51 PDT 
How is this a duplicate of Bug 15695?

This is still an issue in Safari 7.0.3, but not in Firefox ESR 24.5.0, Firefox 29.0, Firefox 30.0 beta, or IE 11.