Clarify behavior of iframes' mainframe event when toplevel browsing context's mainframe advances

[natduca]

@vmpstr can you drive?

[vmpstr]

Yes. To elaborate a bit, we need to clarify what happens when some part of the page triggers a mainframe event that happens to contain an iframe: does it generate an event for the iframe as well? I think that's the question here.

[mithro]

Sorry this ended up being so long, hopefully this is on target for this bug.

If I understand, what you are asking about is the following case;

We have a page (the `top level`) which has multiple iframes in it.
Rendering the `top level` we are going to need the `render data` from each of the iframes.

Generically, I think there are two cases when processing the top level for render data from an iframe;

1. We need to do new render work to create the rendered data for an iframe,
2. We have already rendered data for an iframe we can reused and hence don't need to do any render work for the iframe itself.
3. Is there another option I have missed?

My suggestion would be as follows;

---

• The top level gets a PerformanceMainFrame.
  • cost == duration - idle
  • idle == not doing rendering work for top level or any of the containing iframes.
  • IE The top level isn't idle if there render work for a containing iframe happening.
• In case (1) an iframe gets it's own PerformanceMainFrame which has;
  • startTime == same as top level PerformanceMainFrame
  • duration == same as top level PerformanceMainFrame
  • cost == duration - idle
  • idle == not doing any rendering work for the given iframe.
  • IE The iframe is idle when the top level or a different iframe rendering work is happening.
• In case (2) an iframe doesn't get a PerformanceMainFrame.
  • Maybe the iframe should get a PerformanceCompositeFrame event?

---

This all assumes that you can separate iframe rendering from the top level rendering. I have no idea if this is actually possible or practical, people who have better knowledge of the rendering system around iframes will have to chime in. One solution is that if generating cost is not practical is we can define the cost as being optional for non-top level frames?

Would this work in Chrome? My current guess is that generating cost is practical for out-of-process iframes but not for in-process iframes.

---

Instead thinking in terms of use cases, there are two different situations;

1. A website is iframing in their own content.
2. A website is iframing in third party content.

I think in both cases, the website doing the embedding does care that the iframes they are embedding are causing significant work and making them miss their budget. Hence, it seems pretty clear that the top level's PerformanceMainEvent should include the work to render iframes.

The question is, do the inner iframes care about their PerformanceMainEvents and rendering costs;

• In case (a), everything is under one groups control, hence the need for both inner iframe's PerformanceMainEvent existing and having a useful cost values is probably low. However, if they did have useful cost values it would become very easy to understand which iframe is causing issues[1].
• In case (b),
  • The embedding website probably doesn't have access to the inner frame's PerformanceMainEvents, so it doesn't care.
  • The third party being embedded has no access to the top level frame's PerformanceMainEvents[2]. Hence the inner iframes need PerformanceMainEvents and useful cost values to allow monitor the performance of their own content. I can imagine that Google Maps would probably care about the performance of their embedded maps. Games embedded in Facebook or Google Plus are also another example of users who might care.

@vmpstr does that all make sense? Have I missed something obvious?

---

[1]: Side note: If web developers end up putting content inside a iframe for the sole reason of getting this information it points strongly to needed a generic "element rendering cost" type specification which could be based off this.

[2]: Giving an inner frame access to the top level PerformanceMainEvents could be a possible security issue along other "measuring rendering time" issues that were popularised a while back?

[vmpstr]

It makes sense, you bring up some good points.

I don't think there's one solution for both in-process and out-of-process iframes. The reason for this is that these are treated quite differently.

---

For in-process iframes: Each iframe that is present could be a separate layer, or it can be a part of the layer that contains it. This means that it's pretty difficult to separate which part of raster was a result of iframe raster vs what part of raster was a result of top level raster.

It is theoretically possible to get to the level of whether a tile intersects the iframe, but that's about it (it can intersect both the iframe and top level content).

Additionally we could technically have several overlapping iframes, which would become messy to figure out who gets what.

Consider the following use case: We have a page with an in-process iframe. We add some text to the top level page, which causes layout and everything below the page to be invalidated and rasterized (including iframe content). The iframe itself didn't cause this work, but it is being rasterized. I'm not sure what the correct (and clean) way to divvy up work is in that case.

In particular, the problem is that we do work (javascript/layout/tile management/rasterization) layer and sometimes per tree. This means that if an iframe causes work, then a lot of the work is done on the tree. Likewise, if the work is done on the top level, we do quite a bit of work in the iframe's content. In either case, we do have a main frame event that I believe has be reflected in both top level and iframe requests.

Wdyt?

---

For out-of-process iframes: As you've said, the inner content and outer content don't have access to each other's timings, so this is straight forward in the sense that if we have a new top level frame, we do top level timing; if we have an iframe frame then we do iframe timing. I'm guessing it would be next to impossible to sync these timings (and it would probably be a major security issue).

[mithro]

I had a long chat with @vmpstr today about this topic. I believe the conclusion we came to was;

• My idea is nice in theory, but extremely hard to implement (in chrome at least)
• The difference between same-origin and cross-origin iframes are important.
• @vmpstr was worried about iframes requesting the information and then not getting it.

After thinking about it further, my revised proposal (for the V1 specification) is that iframes don't get frame-timing events.

The reason is;

• We can't produce meaningful information for individual iframes, so the only thing available to iframes is going to be identical to the top level document information.
• For same-origin iframes, they already have direct access to the top level document, so if they want to enable frame-timing or collect the information they can do it by manipulating it.
• For different origin iframes, exposing the frame timing information across the security boundary has some potential to be unsafe (there are often unforeseen security consequences).

@natduca @igrigorik - Do you agree with the conclusion that we should go with the simple "it doesn't work" solution for V1 and then revisit in the future?

[igrigorik]

Resolved via #50.