Page doesn't scroll when opening a section URL |
||||||
Issue descriptionIn ToT, loading a page like chrome://md-settings/appearance should cause the page to scroll to Appearance, but the page doesn't scroll (even if there's enough space for it to scroll). This is a result of https://github.com/Polymer/polymer/issues/3629 -- we need a better indication as to when scrolling is actually possible, as we are trying to scroll before the page is ready.
,
Aug 22 2016
,
Sep 26 2016
what's the status on this? it's blocking desktop's dev channel launchability. this seems to generally be working for me (linking directly to a section in the advanced page scrolls to it), but overscrolling doesn't seem to be working well any more (it happens only sometimes).
,
Sep 28 2016
Yes, this is just an overscroll bug now. We sometimes set the overscroll before the entire page is laid out. I'm not sure what a solution would look like. Maybe (ugh) poll until the section has a height, and then set the overscroll, but only if the user hasn't done any intervening navigations in the meantime?
,
Sep 28 2016
polling was my horrible, potential plan
,
Sep 28 2016
,
Sep 29 2016
After dpapad moved cr-settings out of settings.html, my original plan for dealing with issue 638074 works better: https://codereview.chromium.org/2259163002/ Again, it seems to work... all the tests pass locally... but who knows.
,
Oct 4 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6dabb5a5dcefa2d2a775bd5abdf64f87e8aa2621 commit 6dabb5a5dcefa2d2a775bd5abdf64f87e8aa2621 Author: michaelpg <michaelpg@chromium.org> Date: Tue Oct 04 00:27:28 2016 MD Settings: Fix scrolling bugs and hacks caused by undefined load behavior Imports in <body> cause undefined behavior: crbug.com/638074 We have a bunch of hacks to try to avoid doing things with an invalid DOM. Instead of these hacks, sidestep the problem by moving the i18n import to <head> (yeah, this probably breaks i18n-foo in <body>). The code is less haphazard now, but still a minefield because: * Basic and Advanced attempt to control the scroller simultaneously * settings-main updates the overscroll with no regard for section transitions * settings-main eagerly removes overscroll on "scroll" events, but can't differentiate between user scrolls and Basic/Advanced-initiated scrolls BUG= 637508 , 537359 , 589681 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation Review-Url: https://codereview.chromium.org/2259163002 Cr-Commit-Position: refs/heads/master@{#422625} [modify] https://crrev.com/6dabb5a5dcefa2d2a775bd5abdf64f87e8aa2621/chrome/browser/resources/settings/settings.html [modify] https://crrev.com/6dabb5a5dcefa2d2a775bd5abdf64f87e8aa2621/chrome/browser/resources/settings/settings_main/settings_main.html [modify] https://crrev.com/6dabb5a5dcefa2d2a775bd5abdf64f87e8aa2621/chrome/browser/resources/settings/settings_page/main_page_behavior.js [modify] https://crrev.com/6dabb5a5dcefa2d2a775bd5abdf64f87e8aa2621/chrome/test/data/webui/settings/about_page_tests.js
,
Oct 4 2016
Well, this is mostly done. BUT: Sections can still change size very soon after loading, e.g. the Internet section on CrOS can grow dramatically. This means we scroll to a section and almost immediately scroll up, because the scroll position stays constant (while the area above the URL's section increases). Not terribly sure how to fix this. It also prevents us from testing this bug: https://codereview.chromium.org/2383563004/
,
Jan 6 2017
,
Mar 6 2017
The Internet section does not grow very much without user interaction, and reloading each section did not show any artifacts other than the initial jump to the specified page (section). Marking this one as fixed. If there are concerns about the current behavior we should open a new issue. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tbuck...@chromium.org
, Aug 16 2016