Select in sticky element causing page scroll when rendering `:active` state
Reported by
lizster...@gmail.com,
Jan 25 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: 1. Open up the test page 2. Scroll down the page. 3. Click the select dropdown What is the expected behavior? The main page shouldn't scroll anywhere as the select is fully visible. What went wrong? Page scrolled up to where the element is rendered in the page. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 63.0.3239.132 Channel: n/a OS Version: OS X 10.13.2 Flash Version: If you click outside of the select to ensure it's no longer in focus and active, then scroll the page again, clicking on it will reproduce the problem. When you scroll the page down again with the scroll wheel and the select is still 'active', clicking it again doesn't cause the page scroll.
,
Jan 29 2018
,
Jan 30 2018
I can repro on latest Canary. Let's bisect to see if this is a regression.
,
Jan 30 2018
This is very unlikely to be a regression; I suspect we just have stale sticky data when the select box asks for the current location.
,
Feb 9 2018
I just tested Chrome 58 and this issue is present so it's not a recent regression, at least. Possibly related: https://bugs.chromium.org/p/chromium/issues/detail?id=746590 (and https://bugs.chromium.org/p/chromium/issues/detail?id=754328).
,
Feb 9 2018
Here's another possibly related issue I just reported: https://bugs.chromium.org/p/chromium/issues/detail?id=810895
,
Mar 26 2018
To give an update on this: this bug is caused by stale sticky constraints. I am trying to figure out a patch to make sure they aren't stale, but ran into a tricky bit of code complexity where the focusing/scrolling code is called during lifecycle update (so it's not valid to request a lifecycle advance). Hopefully we will be able to resolve the complexities and fix this, but ultimately this is another indication that sticky constraints need to be a layout-time calculation.
,
Mar 29 2018
,
Jun 12 2018
Issue 851934 has been merged into this issue.
,
Jun 16 2018
I explained the behind-the-scenes reasoning for why this happens and I don't think it really counts as a *bug*, but rather a simple design flaw since the browser engine is programmed in a specific way. Even if it is coded in a way where it would work properly, it likely has some problem with it (hence then it *is* a bug) like smcgruer@chromium.org mentioned. I haven't looked at any of Chrome's source code myself, but my assumption is that it's told to check if an input field is offscreen by comparing the scroll position relative to the actual position written in the document/file. A lot of browsers have this issue and many others don't. The best way to fix this is to simply make it run the check by comparing the element's real-time position instead.
,
Jul 6
Here is a JSFiddle for anyone wanting to work on this issue: http://jsfiddle.net/d3Lku791/ In the meantime, is there a workaround other than storing the current scroll position and restoring it?
,
Aug 14
Issue 873233 has been merged into this issue.
,
Sep 30
I've had this issue for long time as well, but it seems that it works properly now on Chrome Canary 71 :).
,
Oct 1
You are probably looking for a change made after 592438 (known bad), but no later than 592440 (first known good). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/badbd1c5b6149dafb126de7cbf83fa04eb48e339..e1aa11528e75bad7d7676d44970338a8e1c12a6b This was likely fixed by adithyas@'s change in http://crrev.com/https://chromium.googlesource.com/chromium/src/+/e1aa11528e75bad7d7676d44970338a8e1c12a6b |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dtapu...@chromium.org
, Jan 27 2018