Some platforms (so far blackberry) are interested in notifications before a frame loader is deferred and after it is resumed.
Created attachment 135783 [details] Patch
It looks good to me, but I will wait for some "FrameLoader guy" to say something. Btw, it would be nice to say a few words about the usage in the BlackBerry port.
This looks quite redundant - deferring doesn't happen all by itself, the client already knows about conditions that cause it.
(In reply to comment #3) > This looks quite redundant - deferring doesn't happen all by itself, the client already knows about conditions that cause it. The caller does know the conditions that cause deferring and resuming but the notifications are not redundant. The notifications make caller's life easier, otherwise on every call sites the caller need to iterate the frame loaders for the page twice one for deferring and another one for resuming.
Created attachment 135971 [details] Patch v2 Adding explain that the notifications are used for the blackberry porting.
This change still doesn't make sense to me. Load deferring is an implementation detail of WebCore, clients needn't know about it.
(In reply to comment #6) > This change still doesn't make sense to me. Load deferring is an implementation detail of WebCore, clients needn't know about it. Do you think page load is an implementation detail of WebCore? Is it FrameLoaderClient::dispatchDidCommitLoad() necessary for example?
Comment on attachment 135971 [details] Patch v2 I'm not sure it makes sense to notify the client here. Can you explain more about how you're using this notification?
Created attachment 136369 [details] Patch v3 Adding more explaining.
Comment on attachment 136369 [details] Patch v3 Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.