-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generated docs on long pages render text on top of itself #88545
Comments
@mqudsi no worries - rustdoc is used for both docs.rs and the main doc.rust-lang.org website, but docs.rs doesn't have control over the main site. |
Can confirm that problem on my PC in Edge. |
I can't reproduce this in Firefox on macOS, but I can in Chrome on macOS. So I'm guessing it's a bug specific to Blink because I think Chrome and Edge both use Blink, whereas Firefox does not. |
It seems to be a bug with Blink's grid implementation. If I turn off the |
I’m not saying it’s not grid, but just pointing out that changing the display completely changes the layout and so may avoid the problem even if it’s something else. In theory, anyway. |
Fair point. A minimal test case appears to show the same issue but I'll admit that does not necessarily determine the root cause: <!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Test display grid with lots of children</title>
</head>
<body style="display: grid;">
<script>
for (let i = 0; i < 600; i++) {
document.write(`<div>Testing</div>`);
document.write(`<div>Overtype</div>`);
}
</script>
</body></html> |
I think your test case confirms the cause, at least from a black box perspective, sufficiently ;) |
It looks like this issue was previously reported here and there are some relevant links towards the end. Notably a confirmation that there is currently a 1000 row limit to grids in Blink. There is also a recent reddit thread on the issue. |
Do you have an idea @dns2utf8 ? The best would be to not use grid at all. If you have no idea, I'll send a fix in the next coming days. |
I can confirm this with Chromium 93 and IE Edge 91. It works with Firefox 91 and 92 so I assume it is a chrome render-engine bug. |
Yes it's a Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=688640 |
@dns2utf8 Which is why I think we should switch to another way of rendering which doesn't use the current grid at all (firefox also has a limit, it's just a higher one). |
Hm, ... I see your point. |
I don't think this is a good idea. I'd really prefer to not rely on "limits" that could change independently outside of our control. I think we need to find another approach. |
See rust-lang#88545 for more details
One idea I have is that we switch back to the table element if the table is too long. Another one, we use the mobile layout on desktop too if the table is too long. Or something else |
The annoying part is that the left column has to be the width of the largest element. Maybe we could rework that part so it doesn't need something so complicated and keep how it's displayed on mobile? If you have suggestions... :) |
cough tables cough. But seriously, if you use a css reset to remove all browser styling (are we already doing that?) you can use the table layout in the renderer to create code like our current grid (because we are barely using any of the actual grid features). A little bit of css to the cell classes makes it responsive. |
Or maybe we can do even simpler and just set width to both parts to 50% (or 30-70, well up to debate). Like this, the alignment for the right part will work and we don't need to worry about grid or table anymore. |
In the upcoming CSS Grid-2 spec (https://www.w3.org/TR/css-grid-2/#overlarge-grids) there is this sentence:
So we would run into trouble if a table gets longer than 10k entries. However:
To me the spec reads as, the UA (User Agent aka Browser) is free to enforce lower limits if there is not enough memory available. I would like to look at the |
…ements_grid_bug, r=GuillaumeGomez Workaround blink/chromium grid layout limitation of 1000 rows I made this in case we don't come up with a better solution in time. See rust-lang#88545 for more details. A rendered version of the standard library is hosted here: https://data.estada.ch/rustdoc-nightly_497ee321af_2021-09-09/core/arch/arm/index.html r? `@GuillaumeGomez` `@jsha`
…ation of 1000 rows See rust-lang#88545 for more details
See rust-lang#88545 for more details (cherry picked from commit 0bf16af)
This was fixed by #88776, right? |
I'm waiting for #88816 before closing it. |
@GuillaumeGomez Can you add |
…nts, r=GuillaumeGomez Rustdoc migrate to table so the gui can handle >2k constants Closes rust-lang#88545. This PR adds a test for overlapping entries in the `item-table` rust-lang#88545 It currently includes the commit with the workaround from rust-lang#88776
I hope this is the right repo to report this, I wasn't sure if it should go in the main rust repo instead.
The generated docs for pages with a crazy number of items seem to give up on positioning and then just dump all subsequent entries on the same line past a certain point. It looks like it might be related to hardware acceleration, but I'm not sure.
For example, viewing https://doc.rust-lang.org/beta/core/arch/arm/index.html in Chrome 92 on Windows and hitting ctrl+pgdwn to go to the very bottom shows this:
The text was updated successfully, but these errors were encountered: