consider dropping some fields for cross-origin subframes

[fergald]

When a subframe is cross-origin, we should not provide reasons, or URL. It is a bit confusing to see blocked:true and no reasons. Also a url of "" is a little odd.

We don't give an explicit signal that information was hidden (url=="" implies it). Maybe we should have a crossOrigin field or maybe we should use null for these when the subframe is cross-origin. That's an explicit signal that you can't see them vs they are empty. However that does make it a bit more likely that uncareful devs will cause exceptions.

[ErwinHofmanRV]

Hi @fergald,

I've got multiple uncertainties going on with NRR and one of them matches your issue (blocked-flag & crossOrigin), so I hope this is the best place.

I have the following NRR object (urls anonymized/replaced):

{
    "src": null,
    "id": null,
    "url": "https://www.example.com/nl/p123456789/sony-camera",
    "name": null,
    "reasons": [
        {
            "reason": "unload-handler"
        },
        {
            "reason": "masked"
        },
        {
            "reason": "cache-control-no-store"
        }
    ],
    "children": [
        {
            "src": "https://www.youtube.com/embed/Y2IVv5KnrmI?&enablejsapi=1",
            "id": "99097688",
            "url": null,
            "name": "",
            "reasons": null,
            "children": null
        },
        {
            "src": "https://www.youtube.com/embed/Y2IVv5KnrmI?&enablejsapi=1",
            "id": "112044008",
            "url": null,
            "name": "",
            "reasons": null,
            "children": null
        }
    ]
}

And because I know there was a blocked:true flag before, which then changed into preventedBackForwardCache and is now gone again (at least in Chrome v122 and 123), and no single human readable doc available yet (it feels like that at least, I'm eagerly waiting for one on web.dev or MDN), I don't know anymore how to interpret the above.

In other words, how do I recognize if Youtube embed iframes caused issues here? Does the above mean:

• youtube was indeed the reason for a block?
• or just that there was an iframe would could potentially be blocking, but due to no reason being communicated it was not blocking at this instance?

The part that is making me uncertain is the fact that there is no reason value nor any blocked/preventedBackForwardCache flag. Which leads me to another question:

• is it correct that there will be no more preventedBackForwardCache (maybe because the fact being part of an NRR object is already implying that it was blocking after all)?

I'm asking on behalf of a RUM solution where we implemented this about 9 months ago, and we had to change it multiple times already 😅

[fergald]

It is intentional that you cannot know whether a cross-origin subframe caused blocking as that would potentially leak information about that frame (and therefore about the user). This is unfortunate. #9 could possibly improve this situation. If you suspect a subframe is blocking, I thnk the best you can look at the detailed blocking reasons in devtools. You can also play around with removing that subframe in pagehide and restoring it in pageshow. We haven't come up with any better approaches that preserve privacy.

As you said, the explicit boolean has been removed because it is implied by the fact that there are reasons.

We really appreciate people trying out the API during Origin Trials however it is a fact of life of Origin Trials that the API may change as we learn about usage but also as other vendors give their input on the proprosed API.

@rubberyuzu can address comments about mismatch between docs and behaviour.

[rubberyuzu]

Thanks Erwin for reaching out. I'm now working with the writing team to update the developer article. Meanwhile, you can check out this readme, which is mostly up-to-date with the current implementation.

Regarding your example, the main frame (example.com) has at least two blockers that are actionable: "unload-handler" and "cache-control-no-store". "masked" means that there were non-actionable blocking reason that come from implementation details. Or "masked" could mean that the cross-origin subframes were blocking.

[ErwinHofmanRV]

fact of life of Origin Trials that the API may change

Fully aware by the way! NRR + LoAF (and other OT's we participate in) are all quite awesome APIs and exciting to work with too :) But maybe a bit too many simultaneously on our end recently 😅