Test infrastructure to expose whether a browser intends to expose transferSize across origins with TAO

[achristensen07]

With https://github.com/w3c/resource-timing/pull/369 doing a corresponding PR to web platform tests makes them no longer catch regressions in intended transferSize exposure. For example, assert(timing.transferSize == 42) needs to be changed to assert(timing.transferSize == 0 || timing.transferSize == 42). It would be better if we could instead change it to if (internals.allowsCrossOriginTransferSize) { assert(timing.transferSize == 42) } else { assert(timing.transferSize == 0) }. Since the motivation of this is for unit tests, it would probably be distasteful to expose a boolean to the web platform, the implementation of which would just be a hard-coded value. Same applies to encodedBodySize, decodedBodySize, and server timing.

[yoavweiss]

I'm not sure this won't be useful beyond just testing. It may be helpful for RUM providers and developers to know if the browser supports cross-origin resource sizes. Current resource sizes are using "0" as a sentinal to indicate either of "the resource had no body", "the resource is cross origin with no TAO" or (now) "The resource is cross origin and the UA doesn't support that".

It may be useful to add an enum that disambiguates all of these.

@nicjansma - thoughts?

[nicjansma]

Agreed that this could be a useful signal for RUM. We frequently get questions when customers are reviewing the RUM data we collect regarding why some resources or page loads don't have sizing information. If we knew definitively that this was due to !allowsCrossOriginTransferSize vs. missing-TAO that would tell them whether they should chase down their third-party providers to try to suggest adding TAO flags, for example.

Right now we essentially UA-sniff to assume those two states.

[nicjansma]

Discussed on the 2023-03-30 W3C WebPerf call:

https://docs.google.com/document/d/1EBhbMloSye3zu0wyOimaUNEiHi-wnNbeDjo92d4RSzA/edit?usp=sharing

High-level notes:

• Affirmations from a few participants that having a boolean exposed could be useful beyond just testing infrastructure (e.g. in RUM)
• Some concern that this may lead the way for multiple additional boolean variables, though @yoavweiss thinks there may only be a few other useful ones (e.g. on opaque responses)
• @nicjansma minor suggestion that a "negative" boolean like preventsCrossOriginTransferSize be used as all existing browsers won't have this property. i.e. with allowsCrossOriginTransferSize there will be a mixture of browsers (older ones) that allow cross-origin transfer sizes but don't have the value set.
• Group agreed to continue discussion and design of the attribute here

[sefeng211]

I want to raise some similar issues. For example this LCP test assumes the first-paint is always implemented, and also this one (which is not a feature that browsers don't implement, but behave differently). I am trying to understand what folks opinion about them. Do we think they are same issues? If we introduce new boolean flags, do they also qualify the need of having a new boolean flag?

[yoavweiss]

@sefeng211 - I believe we already have supportedEntryTypes to handle this kind of feature detection.

[sefeng211]

Ah right, I missed that one, sorry!

Though I am still not sure whether the boolean attribute is the right approach or not. The original comment from Alex also mentions encodedBodySize, decodedBodySize, and server timing. So clearly preventsCrossOriginTransferSize won't fix for them.

I'd still imagine the ideal solution is the clients of RUM providers can use Reporting API to determine this, and we have something unique for testing.

However, if that's too much work and folks don't like the user agent approach in the test files, maybe this should be something like PerformanceResourceTiming.supportedAttributes? And one for server timing as well?

[yoavweiss]

Though I am still not sure whether the boolean attribute is the right approach or not. The original comment from Alex also mentions encodedBodySize, decodedBodySize, and server timing. So clearly preventsCrossOriginTransferSize won't fix for them.

Yeah, we'd clearly need a better name that represents the reason behind the lack of exposure.

I'd still imagine the ideal solution is the clients of RUM providers can use Reporting API to determine this, and we have something unique for testing.

I'm not sure I see how the Reporting API fits into this..

However, if that's too much work and folks don't like the user agent approach in the test files, maybe this should be something like PerformanceResourceTiming.supportedAttributes? And one for server timing as well?

In this case, the attributes are supported, just not supported on cross-origin cases.

[sefeng211]

Okie..so you want a single boolean value represents this user agent prevents some of the attributes to be exposed on cross-origin cases. Do you want to include the name of those attributes in this single boolean value? What if different agents have different not exposed on cross-origin cases attributes? Looks like the current wording in the spec doesn't allow it, but I think this could happen in the future. I am trying to say that a single boolean value doesn't seem sufficient for this.

For the Reporiting API, I was thinking a new type of report for timing attributes, which specifies the attributes that are not supported in cross-origin case. Now thinking about this again, I suspect this might not fix the RUM use case...maybe...PerformanceResourceTiming.opposeCrossOriginAttributes ?

[sefeng211]

Oh another thing regards supportedEntryTypes, it doesn't help for detect whether first-paint is available as they all belong to the paint type entries.

[yoavweiss]

Oh another thing regards supportedEntryTypes, it doesn't help for defect whether first-paint is available as they all belong to the paint type entries.

That's true..

Any thoughts on a more holistic API to expose variations in support?