New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: weird scrolling behavior in Chrome #40099
Comments
We're using the CSS property |
I wonder if the kind of solution described here or something similar would solve these problems? It's very frustrating not being able to properly navigate the documentation a page at a time or by sliding the scroll bar. It seems to me like the browser should keep elements rendered after it's rendered the first time, which should solve the scrolling problem. It seems like the solution I linked to explicitly does this? |
Yep that looks promising indeed. Would you be interested in sending a PR? On the mean time (and I know this is not a satisfactory answer to that issue, more a temporary workaround), you may find Firefox more suitable to browse the docs as they haven't implemented |
It works fine on macOS Chrome |
I think this also causes an issue if you try to open any URL with a hash in a new tab. It doesn't scroll to the desired method / property. |
I am working on this rn |
This pr fixes the jittery scrolling behavior introduced in nodejs#37301 fix:nodejs#40099 refs:https://infrequently.org/2020/12/resize-resilient-deferred-rendering/
I hate to pile on but this issue has made browsing the API docs an exercise in frustration for a while now. The scrollbar jumps all over the place when trying to drag it, as well as the yellow indicators when you do a ctrl+f. I never end up in the correct place when following an anchor link. I'm surprised there haven't been more reports after all this time, surely it's more than just a handful of us affected? Chrome on Windows here. Firefox seems fine as mentioned. |
@mscdex, for reading the current open Issue, for me, the takes are the following:
Then there's the discussion about if it should be removed:
There's, of course, the approach of doing some JavaScript spaghetti, as I saw in some random blog post. Still, I'm severely against having arbitrary JavaScript code that tries to "fix" the web (by inherently trying to change how certain behaviours happen). What I imagine as an "ideal" solution for now:
Regarding modern technologies: Modern browsers and rendering engines are already smart enough to offload computing from complex parts. I did some synthetic loads on the current API website with Moreover, disabling Of course, some real old phones or hardware would struggle a little. But given that technology is ever-evolving, I doubt someone would consistently open our API docs on a tiny smartphone from 7 years ago... I feel inclined toward the approach/solution I mentioned above. |
I wonder where you get that figure from, in my experience loading the |
Well, the percentile is based on Browserslists on which browsers supporting supporting the 95th percentile. (https://browserslist.dev/?q=Y292ZXIgOTUl) And sorry, I meant the 95th percentile not the 99th. I can at least on all my devices open it perfectly without any issues. Using Chrome DevTools to mimic hardware constrained situations it also seems to work fine. Of course to a certain degree I'm doing an opinionated guess. |
To clarify, do you mean that building the docs locally commenting out the |
No need to rebuild the docs; just disable the property directly on the browser.
I'm not sure I can give you a reliable rendering time or statistics as they're bound to my computer. But by even doing a 6x CPU slow down and checking GPU raster it sounds OK. Feel free to check by yourself. |
Yes you need to rebuild the docs, because
That鈥檚 OK, what I鈥檓 interested in is the difference (on the same CPU) of rendering time, absolute values don鈥檛 matter in this case. |
Well, you know you can just download all the assets, change the style.css and then run a local server 馃槄 I'm not on my MacBook, hence why I didn't have the tools to build the docs. But afaik just downloading a copy of the built website (Ctrl + S) + Editing the CSS files + some random simple
Well, I saw a difference of just shy ~500ms (Mostly) on the Rendering Time. Note that I started the profiling before opening the Website. |
OK so I've got back to my computer, and tried on Chromium 112.0.5615.137 on my M2 MBP: using With Without (I promise I didn't cherry-picked it, I run the performance profiller once on |
Yeah agreed. For me, for example, the rendering time with But honestly speaking, I feel that in the future (with the API Docs redesign), we should eliminate the "all.html" page. It genuinely doesn't make sense to have a gigantic page containing everything simultaneously. No other Docs Page I know does this. All other pages on our API Docs, including http.html, take around 33ms to load... So, all other pages have reasonable loading times. |
|
I genuinely feel right now the fact that we have content-visibility is actually breaking features of the docs pages such as scrolling and anchor links. Not to mention the redesign docs will pretty much not have this, so my 2 cents:
|
Until this is hashed out, there's a trivial incremental improvement that we can make to mitigate some of the usability issues here (which are particularly bad/unusable in Firefox Nightly & Firefox-with- See #48195 - if anyone with the ability to review/merge PRs here wouldn't mind taking a look over there, that would be much appreciated. |
@mscdex this issue maybe resolve by pr above, could you please check it? |
馃摋 API Reference Docs Problem
Location
Affected URL(s):
Description
At least on Linux and with Chrome, if you load a very long page, like the CommonJS modules API page, and you either press the End key or otherwise scroll to the bottom and then attempt to scroll up or hold down the Page Up key, the scroll bar makes a lot of strange jumps (backwards and forwards). Even starting at the top of the page and scrolling down causes the scroll bar to do some large, sudden, and unexpected jumps. However, using the Home and End keys seemingly work just fine.
My guess is there is either some javascript on the page listening for scrolling events in general or on particular elements (like code blocks) and that is somehow causing the weird issues.
The text was updated successfully, but these errors were encountered: