Type in a input in position:sticky container will cause the page to scroll to the origin position
Reported by
si...@yahoo-inc.com,
Jul 10 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Visit the demo http://jsfiddle.net/jcnmd965/ 2. Scroll the page down 3. Type in the input text and it will auto scroll to top What is the expected behavior? Expected to no scrolling when typing. What went wrong? Input in a position:sticky container is considered in the original position and become 'not-in-view'. Since chrome will auto focus the input that is not in view, it scroll to the origin place of the input. Only desktop chrome could reproduce this bug Did this work before? No Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: stable OS Version: OS X 10.12.5 Flash Version:
,
Jul 10 2017
Able to reproduce the issue using #59.0.3071.115 on Mac 10.12.5, Linux Ubuntu 14.04 and Win10. This seems to be a Non-Regression issue as same behavior is seen since M45. Untriaged to get more input from dev on this issue. Same behavior is seen in since M61. Thans!!
,
Jul 10 2017
,
Jul 11 2017
flackr@, smcgruer@ can we get this triaged?
,
Jul 13 2017
We are experiencing similar behavior with an older version of the ace editor (the one included in etherpad-lite), where typing in the editor causes the editor to scroll to the top (putting your cursor below the fold in most cases) We have figured out that this behavior doesn't exist in Chrome 58 so have directed our users to use the Chromium build that is based on. We have specific steps to reproduce in our application (which is an enterprise install) -- we are happy to provide access to this application to chrome devs with a list of steps to reproduce if you are interested.
,
Jul 13 2017
Yi - can you have a look at this? We probably just need to either: i. Make sure compositing inputs are clean before whatever code scrolls to the typing position runs, or ii. Make sure that the code that moves to the typing position is correctly taking sticky into effect. I'm not personally familiar with what code scrolls to current typing position - possibly flackr@ or dtapuska@ would know.
,
Jul 13 2017
,
Jul 14 2017
Agreed with option 2. It looks like the offset we use in LayoutBox::ScrollRectToVisible doesn't take sticky into account.
,
Jul 24 2017
,
Jul 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3bc01c107eed20298c1379996b6e1596189eab66 commit 3bc01c107eed20298c1379996b6e1596189eab66 Author: Yi Gu <yigu@chromium.org> Date: Mon Jul 24 17:24:33 2017 Fix the bug that typing in a sticky box scrolls the page unexpectedly. Previously computing the rect to scroll when revealing the selected sticky box didn't handle the sticky offset correctly due to incorrect document lifecycle which caused unexpected page scroll. Bug: 740417 Change-Id: I87ed4da4ca10fa7be78620ac8a8240084d50b6c5 Reviewed-on: https://chromium-review.googlesource.com/576215 Commit-Queue: Yi Gu <yigu@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/master@{#489006} [add] https://crrev.com/3bc01c107eed20298c1379996b6e1596189eab66/third_party/WebKit/LayoutTests/fast/css/sticky/sticky-input-box-position.html [modify] https://crrev.com/3bc01c107eed20298c1379996b6e1596189eab66/third_party/WebKit/Source/core/editing/FrameSelection.cpp
,
Jul 24 2017
,
Jul 25 2017
,
Aug 3 2017
Issue 702936 has been merged into this issue.
,
Aug 10 2017
Issue 754328 has been merged into this issue. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by nyerramilli@chromium.org
, Jul 10 2017