[Webkit-unassigned] [Bug 157563] New: Resource load cancelled if detaching the first of multiple iframes all loading from the same URL

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed May 11 02:57:44 PDT 2016


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

            Bug ID: 157563
           Summary: Resource load cancelled if detaching the first of
                    multiple iframes all loading from the same URL
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Local Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Frames
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: hyongyoub.kim at navercorp.com

Created attachment 278609
  --> https://bugs.webkit.org/attachment.cgi?id=278609&action=review
Test html pages and cgi perl scripts

Multiple iframes are loading from the same URL. Before the main resource load completes, the first iframe that started the load gets detached from the page via javascript. The other iframes all see cancelled main resource.

test.zip contains two simple test cases. Need cgi/perl enabled webserver.
Case 1:
html/main.html

Case 2:
html/main2.html

Here is case 1 so you do not have to unzip the file.

<html>
<body>
<div id="shadow">
<iframe src="/cgi-bin/slow-iframe"></iframe>
</div>

<div id="empty"></div>
</body>

<script>
function set2() {
  document.getElementById("shadow").innerHTML = "";
}

function set1() {
  document.getElementById("empty").innerHTML = document.getElementById("shadow").innerHTML;
  setTimeout(set2, 1000);
}

setTimeout(set1, 1000);
</script>
</html>

The first iframe ('shadow') starts loading /cgi-bin/slow-iframe.
1 second later: set1 adds the second iframe, which also loads from /cgi-bin/slow-iframe.
2 seconds later: set2 detaches the first iframe from the page.
3 seconds later: slow-iframe finally returns the response.

IE/Firefox/Chrome all show slow-iframe's response in the second iframe. But safari and other WebKit ports show a blank because the load gets cancelled when we detach the first iframe from the page. When detached from the page, FrameLoader calls stopAllLoaders, which ends up cancelling the main resource load. The second iframe waiting for the load to complete sees a cancelled load.

Case 2 is similar but shows the problem with subresource not the main resource. In this case, the main resouce loads quickly so both iframes see the completed resource. But its subresource loads slowly. When the first iframe gets detached, the subresource load gets cancelled.

For case 2, IE/Firefox show the subresource in the second iframe. Safari/Chrome/WebKit ports show blank. Chrome is okay for case 1 because it is not caching main resources in MemoryCache...

This behavior feels like a bug because, without MemoryCache, we would not see cancelled loads. In case people feel like this sort of iframe usage is a far fetched scenario, many sites in China actually do employ some versions of it...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160511/8d8cc014/attachment.html>


More information about the webkit-unassigned mailing list