Open zcorpan opened 1 year ago
I think the real mitigation here is that scrolling won't occur if the initiator of the navigation isn't same-origin:
If the navigationParam’s request has a sec-fetch-site header and its value is "same-origin" set allow text fragment scroll to true and abort these sub-steps.
However, I don't feel too strongly about this since I'm not sure applying focus is super useful anyway (we do set sequential focus for keyboard navigation and accessibility, which are very useful, but I think those aren't programmatically detectable?).
"Focusing steps" takes an element or navigable, so it seems to me there's a logic error here.
The spec adds a monkey patch to make target
the lowest-common-ancestor Element when scrolling to a text-fragment Range.
Hmm, taking a closer look - it seems Chrome doesn't actually apply focus, nor does Safari. I can't think of how applying focus would be useful here and given the potential for leaks it adds I'd err to avoiding the focus steps (for text directives) in the spec. Any objections?
@jnjaeschke what do you think?
https://wicg.github.io/scroll-to-text-fragment/#issue-e253a983 says
and https://web.dev/text-fragments/#privacy says
This suggests the spec here is wrong and focusing target, at least across origins, would be a privacy leak.