Have you tried setting up an automated process which tries to gradually reduce your large codebase to a small one which still reproduces the bug?
Some similar existing projects: Tigris Delta for C/C++ code, Bugpoint for LLVM, and my own DustMite (https://github.com/CyberShadow/DustMite) for D code. I wonder if something like that already exists for HTML.
If I was developing Chrome's compositor, sure, I'd do that.
One difficulty is that the "bad" code is actually generated HTML and CSS. Well, the generated code is fine, it's the browser that eventually has problems with it, but you get what I mean.
There's probably a way to capture that output in buffers over multiple event loops, and then do something like Bugpoint over that output and see if I can't reproduce/reduce the issue.
I'm also not sure if the Canvas drawing I'm doing is part of the issue or not, so I'd probably have to capture that as well...
For whatever reason, the bugs I see manifest as edge cases in Chrome's new compositing system, but only under "load". I've tried to get small examples that show the bugs, and failed.
But since the developers will only accept tiny programs that demonstrate the problem, I'm SOL.
UPDATE: Also, there's no such thing as "WebKit", as though rendering issues, once fixed in "WebKit" are suddenly fixed as long as everyone updates to the last release. It doesn't work like that, because there are numerous rendering implementations built-on top of WebKit -- the ones I run into have to do with Chrome's compositor vs. Apple's compositor. They behave quite a bit differently, and those aren't the only two in use. The same is true of WebKit JavaScript engines and the APIs supported.
There's just no way, as a developer, to treat "WebKit" as a platform. You have to deal with every browser using WebKit separately.
[0] https://github.com/erichocean/blossom