It would be nice if PageGroupLoadDeferrer would call a client callback when loading is deferred or resumed. That way ports could also defer platform-specific timers and long-running jobs that might interact with page loading during this time.
The obvious place for this is in FrameLoaderClient. I propose adding two functions:
willDeferLoading - called for all frames being deferred before any action is taken, in the PageGroupLoadDeferrer constructor
didResumeLoading - called for all deferred frames after they have been resumed, in the PageGroupLoadDeferrer destructor
The above proposal assumes we want to notify the client as soon as loading is resumed. But at this point we're still in the JS interpreter and it will be dangerous for the client to do many things.
And loading can be deferred several times. Consider this sequence:
1) execute JS -> 2) defer loading <...> 3) resume loading -> 4) execute JS -> 5) defer loading <...> 6) resume loading -> 7) execute JS -> 8) return to event loop
The above proposal would call willDeferLoading at point 2, and didResumeLoading at point 3. Then willDeferLoading at point 5 and didResumeLoading at point 6. Client code that schedules a timer at point 3 and wants it to fire at point 8 will need to deal with this.
An alternative would be to put a one-shot timer to call didResumeLoading in the PageGroupLoadDeferrer destructor, so that the client callback isn't made until we're out of the interpreter, so the restraints on client code authors aren't as severe. Then to keep willDeferLoading and didResumeLoading calls balanced, we would only call willDeferLoading if the timer is not active.
Then for the above sequence, willDeferLoading would be called at point 2, and didResumeLoading will be called at point 8.
Now that I've typed all that out, I think it's a bad idea. It's unintuitive, and it means that FrameLoaderClient can't have fine-grained control over what it does with its resources. Creates more problems than it solves. But I'd like a second opinion.