New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 702936 link

Starred by 7 users

Issue metadata

Status: Duplicate
Merged: issue 740417
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-08-03
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Input inside position: sticky element resets scroll to top

Reported by mike...@github.com, Mar 19 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36

Steps to reproduce the problem:
1. Visit https://codepen.io/mikesea/pen/MprQyy
2. Scroll down
3. Input text inside the textarea or input elements

What is the expected behavior?
The scroll position should not be reset when modifying the textarea or input elements

What went wrong?
The page scrolls to the top after each character is input to the textarea or input elements.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 57.0.2987.110  Channel: stable
OS Version: OS X 10.12.3
Flash Version:
 
Labels: Needs-Bisect
Status: Untriaged (was: Unconfirmed)

Comment 2 by r...@opera.com, Mar 20 2017

Components: -Blink>CSS Blink>Editing
FrameSelection::absoluteCaretBounds() does not take position:sticky correctly into account and returns an incorrect rect for scroll alignment. FrameSelection::revealSelection() scrolls as if the element was not sticky.

Comment 3 by yosin@chromium.org, Mar 21 2017

Components: -Blink>Editing Blink>Editing>Selection
Status: Available (was: Untriaged)

Comment 4 by ajha@chromium.org, Mar 21 2017

Labels: Needs-Triage-M57
Cc: sunyunjia@chromium.org brajkumar@chromium.org
The above issue looks similar to  bug 702550 , could any one please confirm it?

Thanks!
Labels: Needs-Feedback

Comment 7 by mike...@github.com, May 12 2017

I am still able to reproduce this on Chrome Canary: Version 60.0.3097.0 (Official Build) canary (64-bit)

Comment 8 by th.b...@gmail.com, Jun 1 2017

I tried to bisect but couldn't find a working version.
It's still broken in 61.0.3116.0 (Official Build) canary (64-bit).
Labels: -Needs-Feedback -Needs-Triage-M57 Needs-Triage-M62
Status: Unconfirmed (was: Available)
Team, please triage and bisect if reproducible.
Cc: rbasuvula@chromium.org
Labels: -Needs-Bisect hasbisect-per-revision OS-Linux OS-Windows
Owner: u...@chromium.org
Status: Assigned (was: Unconfirmed)
Tested in chrome #57.0.2897.110,stable #60.0.3112.78 and Canary #62.0.3173.0 on Mac 10.11.6 and able to reproduce the issue. Not able to reproduce the issue in canary #62.0.3173.0 So providing the reverse bisect details.Below are the Bisect Details:

Good Build: 62.0.3166.0 (Revision- 489161)
Bad Build: 62.0.3165.0 (Revision- 488876)

Bisect URL:
-----------
You are probably looking for a change made after 489006 (known good), but no later than 489007 (first known bad).

CHANGELOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/3bc01c107eed20298c1379996b6e1596189eab66..b12201a1e1689fff89421ec0152459b9dcfb3622

From the CL above, assigning the issue to the concern owner. Probably this change could have fixed the issue.

@ ulan : Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change.

Reviewed-On: https://chromium-review.googlesource.com/583087

Note: Able to reproduce the issue in Ubuntu 14.04 and Win 10.0

Comment 11 by u...@chromium.org, Aug 1 2017

Cc: u...@chromium.org
Owner: rbasuvula@chromium.org
Status: Untriaged (was: Assigned)
rbasuvula@, my code changes testing python script. It does not run in chrome.
Cc: -u...@chromium.org yigu@chromium.org

Comment 13 by yigu@chromium.org, Aug 3 2017

Mergedinto: 740417
NextAction: 2017-08-03
Status: Duplicate (was: Untriaged)
This is a duplicate of  issue 740417  and has been fixed recently.

Comment 14 by yigu@chromium.org, Aug 3 2017

It was landed in 62.0.3166.0.

Sign in to add a comment