[Webkit-unassigned] [Bug 39895] Should have a client callback when page loading is deferred/resumed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=39895





--- Comment #1 from Joe Mason <jmason at rim.com>  2010-05-28 12:53:03 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.