New issue
Advanced search Search tips

Issue 677035 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 672457
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Changing an input's value inside sticky positioned element scrolls to the top

Reported by tofu.ha...@gmail.com, Dec 26 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce the problem:
1. Give body a min-height of 200vh
2. Place element inside body and make it `position: sticky; top: 0;` 
3. Place a textual input inside the sticky element.
4. Scroll down so that the sticky element sticks.
5. Change the input's value by typing (Using JavaScript to change `input.value` does not trigger the bug)

What is the expected behavior?

What went wrong?
The page scrolled to the top

Did this work before? N/A 

Chrome version: 57.0.2963.0 (Official Build) canary (64-bit  Channel: canary
OS Version: 8.1
Flash Version: 

Works fine in Firefox.

See https://s.codepen.io/veganarchist/debug/zoVxdX for a reduced test case
 
Components: Blink>Scroll
Labels: -Type-Bug -Pri-2 hasbisect-per-revision M-56 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: flackr@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 10, Ubuntu 14.04, Mac OS 10.12.2 using chrome reported version #57.0.2963.0 and chrome dev version #57.0.2950.4.

Bisect Information:
=====================
Good build: 56.0.2914.0	Revision(430837)

Bad Build : 56.0.2915.0	Revision(431137)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/afd11b9a1533fd51f690f544bfa879e9a4e15f93..9e23825d88c48013fb892c755106d21c9aebeeb2

From the above change log suspecting below change

Review URL: https://codereview.chromium.org/2488563003

flackr@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Just to update, able to reproduce the issue on windows 7 using chrome version 57.0.2969.0.

flackr@ Could you please look into this issue.

thanks,
Still able to reproduce the issue on Win 7 using latest chrome version 57.0.2976.0.

flackr@ Could you please look into this issue.

Thanks
Cc: rbasuvula@chromium.org
Still able to reproduce the issue on Win 7 using latest chrome version 57.0.2984.0.

flackr@ Could you please look into this issue.

Thanks

Comment 5 by flackr@chromium.org, Jan 18 2017

Cc: smcgruer@chromium.org
Does your fix for  issue 672457  fix this? I suspect they might have the same cause.

Comment 6 by flackr@chromium.org, Jan 18 2017

Cc: -smcgruer@chromium.org flackr@chromium.org
Owner: smcgruer@chromium.org
Though if not, I suspect the solution will be the same - that we need to ensure the inputs are clean before scrolling to the element.
This still reproduces with the fix for  issue 672457 , likely because I very explicitly only forced the inputs to be clean for getBoundingClientRect.

I'll take a look into where in the code we auto-scroll text into view.
Cc: chrishtr@chromium.org
After looking, this is the same underlying issue. There are multiple places in the codebase now where we need to clean the compositor inputs in order to calculate the location of position:sticky elements or their descendants.

We need to determine how to best identify and deal with those cases.
Status: Started (was: Assigned)
Mergedinto: 672457
Status: Duplicate (was: Started)
Duping to  issue 672457  since they have the same root cause. A patch is underway.

Sign in to add a comment