InitiatorType should not single out XHR

[yoavweiss]

Talking to @annevk on WHATWG IRC, it doesn't make sense for initiatorType processing to single out XHR.
Unless there are webcompat issues with deprecating and removing that, it should be folded into the fetch initiator type.

[annevk]

Note that fetch is also not universally supported (per @bakulf) and if this is meant to match the "destination" concept the empty string would make more sense... (Firefox exposed fetch only very recently: https://bugzilla.mozilla.org/show_bug.cgi?id=1432713.)

[annevk]

beacon is another thing that currently is not separated out in any way and local name of the element also seems suspect (e.g., <link rel=stylesheet> is style per Fetch concepts, not link).

[yoavweiss]

@nicjansma raised concerns that changing this may raise risk of web compat (as current reports may rely on the current reporting method. As such, this issue may be a better for the initiator revamp we plan for L3: #132

[annevk]

That issue doesn't say anything about how you plan to address the massive layering problem here (or how L3 somehow reduces the risk of making changes; seems like it can't).

[yoavweiss]

Indeed. The issue just states that we need to collect use-cases for improved initiator info, and then we'll figure out what needs to be exposed based on that. The info exposed should be tied to the Fetch spec as much as possible.
Once we'll have the new mechanism in place, we would be able to deprecate the current initiatorType and hopefully remove it eventually.
The reason I'm moving this to L3 is that this process will take time and require new Resource Timing features, and it shouldn't block publishing L2.

[annevk]

I disagree somewhat. I think having massive layering problems should automatically prohibit something from advancing further.

[yoavweiss]

Maybe I'm missing something. Can you elaborate on what you mean by "massive layering problems"? Is there some way we can deprecate and remove the initiatorType property in the short term without risking breaking content and reports?

[annevk]

That initiatorType returning xmlhttprequest (or any other value) is not grounded in primitives. This problem is present for the entire PerformanceResourceTiming API.

[noamr]

Is this still a problem? Since we're working on Resource timing reporting for HTML resources, it should be straightforward to include the initiatorType when reporting, as the reporter is not fetch itself but rather the caller (that's how the implementations go about it, so to speak).

I think that in general "resource" is a not exactly a fetch term, and apart from the low-level fetch type, it's more of an HTML concept exposed via resource timing.

[annevk]

It doesn't really address the larger issue of different groups making different divisions, but it does solve the layering issue. It's probably too late to solve the former, though I'm still somewhat hopeful we can figure out a way to invoke fetch with the right data and have fetch also do the reporting for the common case to avoid complicating each caller for eternity.

[noamr]

It doesn't really address the larger issue of different groups making different divisions, but it does solve the layering issue. It's probably too late to solve the former, though I'm still somewhat hopeful we can figure out a way to invoke fetch with the right data and have fetch also do the reporting for the common case to avoid complicating each caller for eternity.

I was planning to have that common reporting in the HTML spec, also to ensure predictable order between the reporting and things like the load event. It also fits with implementations, where the "resource loader" is a concept that's somewhat external to the network stack. But it could also quite easily be done inside the fetch spec, with initiatorType as a parameter.

[noamr]

Can this be closed @annevk? Not sure what's actionable here.

[annevk]

So the current solution is that each endpoint needs to create RT entries itself, right? Does that mean that for each new endpoint we separately need to consider a Fetch and RT name? Ideally we'd have a better setup for this, but to be fair it's hard to see one.

[noamr]

So the current solution is that each endpoint needs to create RT entries itself, right?

Right, since each end point might decide that something is an error or to delay responseEnd post-fetch.

Does that mean that for each new endpoint we separately need to consider a Fetch and RT name? Ideally we'd have a better setup for this, but to be fair it's hard to see one.

Yes, with the default being other. It's like this in implementations