Bug 702463 found the presence of multiple refresh drivers and timing issues related to them. This bug is for making the refresh driver unique.

When this bug is fixed, this changeset should be backed out: https://hg.mozilla.org/integration/mozilla-inbound/rev/06091f9ed1dd

How is this supposed to interact with the idea that we throttle different refresh drivers at different rates because they're in background or foreground tabs. Also, having different refresh drivers at places where we're going to want process boundaries in the future seems likely to leave us with less pain in the future when we start adding those process boundaries.

So having different refresh drivers is actually desirable?

I think it is, for the 2 reasons given in comment 2. Curious if bzbarsky agrees.

What was being discussed in bug 702463, I thought, was making the active tab refresh driver get triggered by the chrome refresh driver so that the things chrome and the active tab do are synchronized. For example, I believe chrome handles all the widget geometry changes... In any case, background tabs would have their throttled refresh drivers. The foreground tab would have its own refresh driver too, but would just register as a refresh observer on the chrome driver when it had observers instead of starting its own timer. The question of process boundaries is an interesting one. One obvious option is that in the multiprocess case we'd trigger the foreground refresh driver off a notification from the parent process instead of a timer. Maybe we should set things up like that in the single-process case too.

(In reply to Boris Zbarsky (:bz) from comment #5) > The question of process boundaries is an interesting one. One obvious > option is that in the multiprocess case we'd trigger the foreground refresh > driver off a notification from the parent process instead of a timer. Or in the OMTC case, that notification could come from the OMTC thread.