The testcase here is a little complex:
a.html:

<script>
setTimeout(() => {
  console.log("in first setTimeout");
  setTimeout(() => console.log("in second setTimeout"), 2000);
}, 2000);
window.addEventListener("load", () => {
  setTimeout(() => location.href = "b.html", 0);
}, {once: true});
</script>

b.html:

<script>
window.addEventListener("load", () => {
  setTimeout(() => history.back(), 0);
}, {once: true});
</script>

In Firefox, this logs:

in first setTimeout
in second setTimeout

In Servo, this logs:

in first setTimeout

When we navigate away from a page, we suspend any timers scheduled for that page:

When we traverse history to a suspended page, we resume the timers for that page:

To ensure that we don't just fire all the timers that would have elapsed while the page was suspended, we use the suspension_offset value to add an offset when determining whether a timer is ready to fire or not:

• servo/components/script/timers.rs

  Lines 241 to 247 in 41b1a87

  	fn base_time(&self) -> Instant {
  	let offset = self.suspension_offset.get();
  	match self.suspended_since.get() {
  	Some(suspend_time) => suspend_time - offset,
  	None => Instant::now() - offset,
  	}
  	}

• servo/components/script/timers.rs

  Lines 204 to 210 in 41b1a87

  	let base_time = self.base_time();
  	// Since the event id was the expected one, at least one timer should be due.
  	if base_time < self.timers.borrow().back().unwrap().scheduled_for {
  	warn!("Unexpected timing!");
  	return;
  	}

This calculation works for all timers that were already scheduled when the page was suspended, but it's incorrect for new timers that are scheduled after the page is resumed. The testcase fails that condition and prints the warning log and the scheduled timer never fires, since the scheduling mechanism thinks that it already ran.

This is the underlying cause for at least one of the bfcache tests timing out with #39421.