One of the signatures of bug 1542485 points here:

    // SpinEventLoopUntil is unfortunate, but ultimately it's the best thing
    // we can do here given the constraint that we need to ensure that
    // the preferences on disk match what we have in memory. We could
    // easily perform the write here ourselves by doing exactly what
    // happens in PWRunnable::Run. This would be the right thing to do
    // if we're stuck here because other unrelated runnables are taking
    // a long time, and the wrong thing to do if PreferencesWriter::Write
    // is what takes a long time, as we would be trading a SpinEventLoopUntil
    // for a synchronous disk write, wherein we could not even spin the
    // event loop. Given that PWRunnable generally runs on a thread pool,
    // if we're stuck here, it's likely because of PreferencesWriter::Write
    // and not some other runnable. Thus, spin away.
    mozilla::SpinEventLoopUntil([]() { return sPendingWriteCount <= 0; });

SpinEventLoopUntil is indeed unfortunate and should be avoided. But there is also a chance, that the increase/decrease of sPendingWriteCount is quirky during shutdown.

Sorry for the delay on the needinfo. Clearing assuming that the response in bug 1636925 is adequate?

Thanks for the explanation! I am still a bit puzzled then if we really should interrupt PreferencesWriter::Write, but that is a different question.