What should happen when the last valid <meta name="referrer" content="..."> tag is removed?

[a4sriniv]

Context: https://html.spec.whatwg.org/multipage/semantics.html#meta-referrer

My interpretation of the current spec is that when we remove the last valid <meta name="referrer">, we just leave the document's referrer policy unchanged. But that isn't consistent with the scenario where we have two valid <meta name="referrer">s and we removed one of them; in that situation the document's referrer policy is updated to the policy specified by the remaining <meta>. To me the expected behaviour for scenario 1 would be to reset the document's referrer policy to the default (whatever it was before we encountered the first <meta> tag, so either the value in the response-header or "strict-origin-when-cross-origin").

Chromium's implementation seems to not change the document's referrer policy in both scenarios, which doesn't seem right to me either. It also sets the document's referrer policy to the policy of the last valid that has been processed ("processed" here also includes any modifications to the content attribute). This doesn't follow the spec which says that we should use the last valid <meta name="referrer"> in tree order.

[domenic]

Yeah, that seems totally broken. Good catch!

I can't find any good tests for this part of the spec in a quick browse through https://wpt.fyi/results/referrer-policy?label=experimental&label=master&aligned . I think the best path here is:

• Write tests against the corrected version of the spec (which sets the referrer policy to the empty string if there are no such meta elements). See who passes them.
• If we have at least one browser passing that, then we should probably try to get the others (including Chrome) to converge, and fix the spec.
• Otherwise, if the spec is completely out of touch with reality, then we should probably reconsider.

Another thing which this section of the spec implies which I don't see tested is that if such meta elements are inside a shadow tree, they should not have any impact. Fun...

[smaug----]

FWIW, I was reading some relevant code in Firefox and I think it is also following the current spec where removing meta doesn't change anything. And it is also doing the same as Chrome that it uses that last meta valid element, not tree order.
The reason for the current behavior is https://bugzilla.mozilla.org/show_bug.cgi?id=1653474
See also comment 4 there.

cc @sefeng211

[domenic]

@a4sriniv wrote some tests for the current spec behavior in web-platform-tests/wpt#37095. According to https://wpt.fyi/results/referrer-policy/generic?label=pr_head&max-count=1&pr=37095, nobody passes them.

It sounds likely that Chrome and Firefox have the same behavior here, and maybe Safari too. (We'll work to confirm that with tests.) In that case, are people generally OK with changing the spec to match implementations? Or do they think the spec is good and we should try to do a coordinated implementation move?

I guess we should also investigate theme-color and color-scheme, which use similar (but not the same...) algorithms.

[domenic]

@a4sriniv updated his tests and confirm that everyone matches Chrome's behavior. So, I put up a PR in #8587 to fix that. I think we should just merge that, and if we want to reconsider changing to better behavior in the future, we can do that separately.

I investigated theme-color, color-scheme, and supports-reduced-motion for Chromium (source), and they all work in the more-reasonable way the current spec suggests. viewport, handheldfriendly, and mobileoptimized appear to use referrer-like weird behavior, but they are not really standardized...