This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22560 - [imports]: Recursion?
Summary: [imports]: Recursion?
Status: RESOLVED INVALID
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20683
  Show dependency treegraph
 
Reported: 2013-07-03 17:27 UTC by Nathan Hammond
Modified: 2013-07-19 15:03 UTC (History)
1 user (show)

See Also:


Attachments

Description Nathan Hammond 2013-07-03 17:27:36 UTC
It's sub-imports all the way down if we're not careful. This should probably specify how to handle the case where a document imports itself, or, more likely, accidentally imports a cycle.
Comment 1 Dimitri Glazkov 2013-07-18 20:11:33 UTC
I am pretty sure we already handle recursion, even this early in the spec:

"If LOCATION is already in the loaded import list, let IMPORT be the imported document for LOCATION and stop."
Comment 2 Nathan Hammond 2013-07-18 21:59:29 UTC
My concern isn't for infinite recursion of pulling in the resource (easily handled with the collection of downloaded resources), it's that the user-agent rendering approach is unspecified when it encounters that behavior. (I don't know if there is a solution to this in the HTML Parsing spec, say for example, with iframes, if so, please forgive my ignorance.)

Aside: imports that load in a dynamically generated file that is different on each request could get hairy, but that might be an edge case that this spec doesn't care about.
Comment 3 Dimitri Glazkov 2013-07-18 22:03:52 UTC
(In reply to comment #2)
> My concern isn't for infinite recursion of pulling in the resource (easily
> handled with the collection of downloaded resources), it's that the
> user-agent rendering approach is unspecified when it encounters that
> behavior. (I don't know if there is a solution to this in the HTML Parsing
> spec, say for example, with iframes, if so, please forgive my ignorance.)

Can you explain this to me a bit more? I don't understand the problem yet.

> Aside: imports that load in a dynamically generated file that is different
> on each request could get hairy, but that might be an edge case that this
> spec doesn't care about.

Sure. You should be allowed to shoot yourself in the foot. We're not a nanny state system :)
Comment 4 Nathan Hammond 2013-07-19 03:45:32 UTC
I think it is easiest to describe by example:

***

GET /recursion.html

<html>
<head><title>RECURSION!</title></head>
<body>
<h1>This is recursion.html</h1>
<iframe src="/recursion.html" />
</body>
</body>
</html>

***

- Firefox currently doesn't render the iframe's content at all.
- WebKit (Chrome + Safari) renders one deep.
- Opera (Presto) renders 4 deep.
- Cycles stop at number in cycle (N) * (rendering depth) from above.

What *should* the behavior be for the representation of rendering for recursive imports? It doesn't appear to be specified anywhere as there isn't a single agreeing implementation across the three engines I have readily accessible.
Comment 5 Dimitri Glazkov 2013-07-19 15:03:08 UTC
(In reply to comment #4)

> What *should* the behavior be for the representation of rendering for
> recursive imports? 

Unlike iframes, the imports aren't rendered. I still don't understand the problem you're trying to describe.