Allow same-document navigation?

[Treora]

In the algorithm to “determine whether a navigation should allow a text fragment”, step 3 forbids applying a text fragment when performing a user-triggered navigation within the same page:

3. If the document of the latest entry in document’s browsing context's session history is equal to document, return false.

i.e. Forbidden on a same-document navigation.

I wonder, what kind of risk would this mitigate?

I had noticed this behaviour while trying the polyfill playground in Chromium, but assuming it was simply a bug I adjusted the polyfill to make up for it (a bit hacky, by listening for link clicks). But now I got a little confused as it appears to behave according to spec; while unless I overlook something, this looks like a relatively risk-free scenario, and the behaviour differs from how normal fragment identifiers are handled. Any clues?

[bokand]

Similarly to #137, this is a (maybe mildly paranoid) fear of attackers finding a way to navigate and observe a text-fragment navigation on a page. The thought was that full navigations are slower, more noisy, and more user-visible that this risk was somewhat reduced. Additionally, pages that want to do this same-doc can achieve it with some script (though I agree that's an unfortunate thing to ask authors to do).

IMHO, I feel this one is a bit more shaky than #137 and would be supportive of seeing if we can remove it. I'd have to check with Chrome security if they'd be comfortable with that.

[bokand]

I think I just forgot to update this issue, both Chrome and the spec no longer restrict same-document navigation (with some caveats around user gestures and window opener restrictions).

[bokand]

Err - correction, same-document navigation was still restricted by spec but I just merged #239 which fixes that.