[webkit-dev] how to create a test that can perform actions while resources are still loading?

Jenn Braithwaite (胡慧鋒) jennb at google.com
Thu Oct 7 17:12:15 PDT 2010


I need the inline script to be in the iframe content so that the test does
not execute until the iframe has started loading (but has not completed).  I
tried the php below, but the script doesn't execute until after the sleep. I
don't know php.  Is my php wrong?  Or does DRT buffer the response until the
entire response is complete?

<?php
header("Expires: Thu, 01 Dec 2003 16:00:00 GMT");
header("Cache-Control: no-cache, no-store, must-revalidate");
header("Pragma: no-cache");
header("Content-Type: text/html; charset=utf-8");
echo("<script>parent.opener.test();</script>");
ob_flush();
flush();
sleep(10);
?>

Thanks,
Jenn

On Thu, Oct 7, 2010 at 8:15 AM, Ojan Vafai <ojan at chromium.org> wrote:

> On Wed, Oct 6, 2010 at 4:42 PM, Darin Adler <darin at apple.com> wrote:
>
>> On Oct 6, 2010, at 4:36 PM, Jenn Braithwaite (胡慧鋒) wrote:
>>
>> > I've also tried making this an http test using a slow loading iframe,
>> but the window onload handler for the page does not run until after its
>> iframe has finished loading.
>>
>> This seems OK. You can put your test code somewhere other than the load
>> handler. For example, an inline script:
>>
>>    <script>
>>    test();
>>    </script>
>>
>> That will run right away and won’t wait for the window load event.
>>
>
> I'm not 100% sure, so take this with a grain of salt, but I think there are
> cases where iframes the load immediately (e.g. if the resource is cached).
>
> To avoid race conditions, I think you need the frames to actually never
> finish loading. I thought there were some HTTP tests that have resources
> that intentionally never finish loading. I'd look in the
> LayoutTests/http/tests for files with 'slow' in the name.
>
> Ojan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101007/cbebb841/attachment.html>


More information about the webkit-dev mailing list