We now store two independent locations for an omni.jar, allowing GRE/XRE and
XUL application to each have their own omni.jar. And since xulrunner setups
are very independent from the XUL applications, we implement support for both
omni.jar and non omni.jar cases in the same runtime, with the side effect of
allowing to switch from one to the other manually without rebuilding the
binaries.
We let the mozilla::Omnijar API handle both cases, so that callers don't need
too much work to support them.
We also make the preferences service load the same set of preferences in all
the various cases (unified vs. separate, omni.jar vs. no omni.jar).
The child process launcher for IPC is modified to pass the base directories
needed for the mozilla::Omnijar API initialization in the child process.
Finally, the startupcache file name canonicalization is modified to separate
APP and GRE resources.
This implements proposal 3 from bug 650379 comment 13. The main difference
between TYPE_REPEATING_PRECISE and TYPE_REPEATING_PRECISE_CAN_SKIP is to not
AddTimer the REPEATING_PRECISE_CAN_SKIP timer until after the callback has run;
this guarantees that no more timer events will be posted until after the
callback finishes executing. A secondary change is to make
REPEATING_PRECISE_CAN_SKIP timers advance their firing time to mDelay from when
PostTimerEvent is called, not mDelay from the old mTimeout. While this arguably
makes them less precise, the alternative is that if a timer is significantly
delayed for some reason (e.g. because the user puts the computer to sleep for a
while) it will then fire a whole bunch of times to "catch up" to where it's
supposed to be, advancing its firing time by mDelay at a time. That seems
undesirable.
An alternate approach would have been to readd the timer from inside
PostTimerEvent, but only if we're not in the middle of firing the timer. That
would allow more precise timers in the case when the callback is not taking too
long, but still handle gracefully the case when the callback is
slow. Unfortunately this falls down if something _else_ is hogging the main
thread event loop (e.g. some other timer has a slow callback, or whatever); in
that case we would post multiple events for the one precise timer while the
event-loop-hogging operation is running. So I don't think we should do that.
We now store two independent locations for an omni.jar, allowing GRE/XRE and
XUL application to each have their own omni.jar. And since xulrunner setups
are very independent from the XUL applications, we implement support for both
omni.jar and non omni.jar cases in the same runtime, with the side effect of
allowing to switch from one to the other manually without rebuilding the
binaries.
We let the mozilla::Omnijar API handle both cases, so that callers don't need
too much work to support them.
We also make the preferences service load the same set of preferences in all
the various cases (unified vs. separate, omni.jar vs. no omni.jar).
The child process launcher for IPC is modified to pass the base directories
needed for the mozilla::Omnijar API initialization in the child process.
Finally, the startupcache file name canonicalization is modified to separate
APP and GRE resources.
