[webkit-dev] setTimeout as browser speed throttle

[Darin Adler]

This debate is not new. We tried this in WebKit, when we first  
released Safari.

We repeatedly encountered pages that behaved well in other browsers  
and did not behave well in Safari, and the root problem was that they  
had an effective minimum timer value.

It's arrogant to say that it's a website problem. Until the browser  
has a large market share, almost all misbehaving sites are browser  
problems, not website problems.

We saw similar issues with GIF frame timing before we got the minimums  
right there too.

> This still implies there is a meaningful compatibility hit to making  
> this change.  I have not yet seen any reason to agree that is the  
> case (in the sense of "CPU usage is not a web compatibility issue").


This is an incorrect straw man argument that you're putting forward  
repeatedly and forcefully.

We started the Safari project with the naive view that there was no  
need for a minimum timer value. Then we changed this in WebKit because  
of sites that were misbehaving and real bug reports. The new value is  
clearly close enough to the value in the top market share browsers  
that these incompatibilities are effectively a thing of the past.  
Unless we bring them back by removing that minimum again!

You keep stating that CPU usage isn't "a compatibility problem" and  
that these concerns were not real. But that seems to be an unimportant  
semantic distinction. We had to do this to get Safari to behave  
properly with many real websites. I'm sorry that it's difficult to  
quickly find examples now, but I trust there are still many sites out  
there with this issue.

After the many years of the challenging task of fixing incompatible  
websites one at a time, I'm loathe to undo a change that was made to  
fix specific websites. Some of the value in the WebKit project is the  
accumulated knowledge about what matters in practice for  
compatibility. This is definitely one of those things.

     -- Darin