That may well be true. But what others in this thread are arguing is that it would also not be terrible if everyone else switched to WebKit too, and I believe they're wrong about that.
> can't you just submit bugfixes for the bugs that are parallelism bottlenecks?
You mean bugs like being written in C++ and not architected around parallelism?
Bolting on parallelism is _hard_. Have you ever tried doing that with an existing multi-million-line C++ codebase? I've tried with Gecko, and I've spoken with people who have tried with WebKit, as well as reading a good bit of WebKit source, and it's not really feasible unless you drop everything else and focus all your energy on it. And maybe not even then.
> are there any examples of WebKit "bugs" that prevent parallelism that you could not fix yourself
And get the patches actually accepted in WebKit? Lots.
Again, you seem to think the problem is some small issues here and there, whereas the problem is more that you have lots of code touching non-const data through C++ pointers, which means that if you try to parallelize you either get tons of data races or lock contention that kills performance or most likely both.
> At the end of the day, all you guys need to defend is the interface, not the implementation
As long as there are multiple implementations. Unless you include in "interface" everything that's web-visible, but policing that is a huge endeavor that no one working on browser implementations has the manpower for.