Which Documents in a crashed process actually send reports?

[domfarolino]

The specification doesn't specify which Documents/frames in a crashed process actually send reports. Specifically, nothing is said about how many or which frames belonging to a particular origin actually send crash reports, if there are multiple same-origin frames in the crashing process.

There are various options available to us here:

1. Send reports for literally every Document hosted in the crashed process
2. Send reports for main frames and any iframe that is cross-origin with its parent
   • For A->B->A nesting cases, this would send two reports for origin A: one for each frame in the crashing process
   • This could conceivably be valuable if the grandparent A and grandchild A were intentionally served with two different reporting endpoints
3. Send reports for only the highest-level frame in the tree for a particular origin. In the A->B->A case, we'd only send one report for origin A: the main frame's report.

As of right now, there's not very much context data attached to each crash report, so whether we send a single report or multiple ones doesn't really matter, since the report data itself doesn't change very much.

But as crash reports get more and more context data, the issue of scoping/coalescing/sending matters more and more. This is particularly relevant in light of:

• is_top_level: Additional signal: is_top_level #20, Add is_top_level and page_visibility bits #23
• visibility_state: Adding support for additional context / dimensions in the crash report #14 (comment)
• A new key-value storage API to associate arbitrary data with crash reports: Expose a JS API to programmatically add additional client context #15

As all of the above proposals get incubated, context data that might be relevant to a specific document can make its way into a crash report, so tightening things up in the specification will help with developer predictability so they know which frames are actually responsible for sending their state along with crash reports.

---

Proposal

Regarding the three options I enumerated above, my vote would be for option #3, which seems like a good tradeoff for predictability and lack of redundancy. Chromium is kind of documented to do #2, but actually does #3 in practice, which I think seems reasonable. But discussing this more regardless makes sense.

[nhelfman]

Not sure I fully understand the different proposals, but I would like to share a key scenario for this API. It is important for us to being able to report on crashes of embedded iframes.

For Microsoft Office apps it is necessary to ensure we have crash reports for each frame and sub-frame as this technique is heavily utilized as part of the architecture. For example - the hosting frame of a document is usually very light weight an unlikely to crash, while the embedded frame (which is on a different origin) is more likely to crash since it contains the main app logic.

So, if option 3 prevents sending reports for embedded frame (the language says "Send reports for only the highest-level frame in the tree for a particular origin") then I would not vote for it. Can you help clarifying this?

[domfarolino]

So, if option 3 prevents sending reports for embedded frame (the language says "Send reports for only the highest-level frame in the tree for a particular origin") then I would not vote for it. Can you help clarifying this?

Yes, I'm trying to get across the fact that each origin in a crashed process will generate a single crash report, but the report will be sent with the context from the topmost Document of that origin. So in the scenario you mentioned where a lightweight top-level Document hosts a crashy cross-origin iframe from a different origin, if that cross-origin iframe's process crashes, the browser will send a single crash report for that cross-origin iframe. That's how Chromium-based browsers work today, and that's what I'm proposing we clarify in the spec.

Where it gets interesting is if you have a lightweight top-level Document which hosts a crashy same-origin iframe. We still generate a single report for that origin in the crashing process, it's just that the report will say is_top_level=true, because even though the iframe might've technically caused the crash, per the proposal above, the report will be generated from the perspective of the topmost frame of the crashing origin. And that's the top-level Document of the crashing origin.

[domenic]

Note that the explainer references issue #24 when discussing this issue, but it should reference this issue (#25).

[domenic]

Where it gets interesting is if you have a lightweight top-level Document which hosts a crashy same-origin iframe. We still generate a single report for that origin in the crashing process

In this A -> A scenario, what happens if the same-origin iframe does window.crashReport.set("x", "y")? Will the top-level report include x=y, or not?

[domfarolino]

Just as the report will not include any other default reporting context from the iframe (its visibility, or its top-level-ness), it will also not include any developer-supplied context provided via the crashReport API. Really, this is just a limitation of how Chromium sends these reports right now, and nothing in the spec necessarily mandates this (this issue is just about synchronizing the spec and the only implementation so far).

So I guess I'm making the argument that because this was a problem before the window.crashReport API, it shouldn't block that API. But you can argue that this limitation/quirk is so weird and severe, that we really shouldn't pile and introduce a new API that adds way more information to the reports that gets dropped in this weird scenario, thus exacerbating the problem.