Chrome and Firefox both choke on CSS Grid, but one of them renders 10x the other one!
As a programmer, it’s your job to constantly come up with side projects that will eat up your free time and then be abandoned because it’s no longer challenging! The latest idea I’ve come up with was to build a website on Github Pages for reading and searching through Shahnama. This resulted in an interesting experience with the two giants of web browsing that I wanted to talk about. But first, allow me to explain what Shahnama is.
Shahnama is the national epic of Greater Iran, telling the story of the kingdoms and empires that rose and fell in this region since the start of civilization. Shahnama is actually a long poem written in the mathnawi system. How is this related to web design, you might ask! In mathnawi, verses come in the form of melodic couplets, each consisting of two hemistichs that rhyme with one another. As a result, such poetry is often shown like the image below:
As you can see, this looks like a perfect opportunity to use the not-so-new feature in CSS grids! The setup is pretty simple. Every hemistich comes in its own block, and the parent gets the following CSS class to enable the grid and set up a template for the contents:
After doing so, I immediately loaded up the SPA I’m building in Nuxt.js 2.15.7 in my usual browser, Google Chrome. At first glance, everything looked alright. But then remembered that the version of Shahnama I have collected by scrapping this wonderful website comes in 88830 hemistichs. The scrollbar looked awfully small for 44415 verses. Hitting the End Key revealed the following atrocity:
What we’re seeing here is that after a certain number of hemistichs, the rest have all been overlayed on top of one another, forming that giant dark rectangle. The interesting thing is that the last shown hemistich, به خون پری چهرگان تشنه بود, is precisely the 2000th hemistich in Shahnama! Why this particular number? It’s not the upper limit on any of the typical data types you’ll find in C. So, what is exactly at work here? I think answering this question requires looking into the source code of Google Chrome 91.0.4472 that I got from the Arch User Repository. But let’s move on!
I then thought of my old friend, Firefox, whom I haven’t talked to in a while. Manjaro kept it updated for me, so I dived right in. The result is exactly the same!
Well, not exactly the same, if I want to be honest. In fact, the last properly rendered hemistich by Firefox 91.0.2 that I have installed from the official Manjaro repository is precisely the 19998th hemistich in Shahnama! I have no idea why this number is just 2 places away from being 10x that of Chrome!
This behavior was reproducible in both browsers. I restarted both browsers, cleaned up every other tab and background task, ensured there’s enough memory, and even reinstalled the same version from scratch. The result remains the same. This can only mean that this limitation is imposed by the developers themselves. I thought to myself that this could be related to the RAM usage of the browsers. We have KSysGuard to investigate that:
Don’t mind WebStorm hugging almost 2GB of RAM at the top! If we sum up the processes created by each browser, Chrome is occupying 952MB of memory, while Firefox is using 622MB, rendering 10x more content! Neither browser was experiencing any considerable lag during the experience. However, Ctrl+F took a bit longer in Chrome than it did in Firefox. But to be fair, I expected Chrome to use much more RAM than these rooky numbers!
I’m curious to know what leads one browser to render 2000 blocks while the other renders 19998 before choking and overlaying all the remaining blocks on top of one another! Let me know if you have any ideas.