[webkit-dev] C++ callback at same-ish point as DOMContentLoaded javascript event?

[Maciej Stachowiak]

On Nov 16, 2008, at 5:34 PM, Aaron Boodman wrote:

> On Sun, Nov 16, 2008 at 5:33 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>>
>> On Nov 16, 2008, at 5:16 PM, Maciej Stachowiak wrote:
>>
>>>
>>> On Nov 16, 2008, at 2:53 PM, Aaron Boodman wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'd like to run some C++ around the same point as the  
>>>> DOMContentLoaded
>>>> event is fired. Importantly, I need this to happen *before* the
>>>> window's onload event fires.
>>>>
>>>> FrameLoaderClient::dispatchDidFinishDocumentLoad is usually fired  
>>>> at
>>>> the right point, but it can sometimes happen after window.onload.
>>>> Would a patch to add something like
>>>> dispatchDidHandleDOMContentLoadedEvents to FrameLoaderClient be
>>>> accepted? Or is there some better way to do what I want?
>>>
>>> I believe dispatchDidFinishDocumentLoad() will be called right  
>>> after the
>>> DOMContentLoaded event is dispatched. So I don't think a new client
>>> interface is needed.
>>
>> Oops, I didn't read your email thoroughly enough before replying. I  
>> think if
>> the "load" event gets dispatched first sometime, that is likely a  
>> bug. I
>> think moving the dispatchDidFinishDocumentLoad() above the  
>> checkCompleted()
>> may fix it.
>
> Yes, that's exactly the problem. Is it OK to move things around like
> this? I'm just not sure what the contract that embedders are expecting
> from this interface is.

I think the only port with enough compatibility history for this to be  
a potential issue is the Mac port. On the Mac port, this client call  
is used to dispatch an Objective-C delegate method which is not public  
API, so use should be limited to Apple-internal (unless third-party  
apps are using internal non-API calls, which is possible but fairly  
unlikely in this case).

Searching Apple's internal source base, the only client of the WebKit  
delegate call I can find is Safari, and I believe this change would be  
an improvement for Safari's use from the reading of the code.

In conclusion, I would say it is ok to change it. If we find some  
third-party app that for some reason requires the old behavior, I  
think a one-off compatibility hack for such an app would be an  
acceptable solution.

Regards,
Maciej