Browser hacking: Let's make "Cookie Clicker" playable in Ladybird!

I love Andreas Kling's "Browser hacking" series on YouTube where he fixes various issues Ladybird has with specific websites. E.g: Fixing a CSS layout bug found by chessboard.js - [link] Let's make "Cookie Clicker" playable in Ladybird! - ▶ this video He's very good at articulating his thought progress and it's always really interesting to see how he reduces the bug down into a minimal reproducible example.

in “Early stages of Google Docs support in the Ladybird browser” · View on HN

Of course you are correct that supporting Twitter or any service is a moving target, so long as it changes. But that doesn't mean specific bugs can't be captured in a test case. Watch this video of Andreas doing exactly this, albeit for a simpler web app ▶ this video At one point, he deletes half the HTML file to isolate where in the site the problematic code is. In a way doing a kind of binary search. After a few iterations of this, he comes up with a very small case that exhibits the problem he's trying to solve. It's clear he knows his way around the codebase and where to make changes, but isolating these test cases is probably as important. And presumably if you fixed enough of these issues (while following the specs), 99% of the modern web should work just fine.

in “We're building a browser when it's supposed to be impossible” · View on HN

I can sympathize with the authors love/hate relationship with tests, but I can’t help feeling like it’s because we as developers so often test the completely wrong things. I don’t typically write tests, but they do make sense for a few cases (specifically end to end tests that look for well defined outputs from well defined inputs). I was inspired by Andreas Kling’s method of testing Ladybird, where he would find visual bugs, recreate the bug in a minimum reproducible example, fix the bug, then codify the example into a test and make sure the regression was captured in his test suite[0]. This led to a seemingly large suite of tests that enabled him to continue modifying the browser without fear of regressing somewhere. I used this method of testing while I was writing a code highlighter that used TextMate grammars. Since TextMate grammars have a well defined output for some input of code + grammar, I was able to mimic that output in my own code highlighter and then compare it to TextMate’s output for testing purposes. I wrote a bunch of general purpose tests, then ran into a bunch of bugs where I would have mismatched output. As I fixed those bugs, I would add the examples to my test suite. Anyways, my code highlighter was slow, and I wanted to re-architect it to speed it up. I was able to completely change the way it worked with complete confidence. I had broken tests for a while in the middle of the refactor, but eventually I finished the refactor. As I started to fix the b

in “How I Program in 2024” · View on HN