Bug 39895 – Should have a client callback when page loading is deferred/resumed

• Status: UNCONFIRMED
• Component: WebKit API

[Joe Mason]

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

[Joe Mason]

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.

For example, if the client tried to inject some javascript while loading was deferred, this would cause problems.  So the obvious thing to do is queue the script until loading is resumed.  But at this point we are still in the interpreter so we can't call executeJavascript.  We need to wait until it returns to the event loop, such as by setting a one-shot timer.

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.