search

WICG / scroll-to-text-fragment

Proposal to allow specifying a text snippet in a URL fragment
Other
586 stars 43 forks source link

Behavior for performance.getEntries() #223

Open annevk opened 1 year ago

annevk commented 1 year ago

It seems that with

performance.getEntries().find(({entryType})=>entryType==='navigation').name

Chrome at least is more selective about what it ends up stripping from the URL.

It seems to me that should be consistent with document.URL.

othermaciej commented 1 year ago

Is it even intended spec behavior that Navigation Timing is a loophole around directive stripping from the URL, or should it be filed as a Chromium bug?

annevk commented 1 year ago

That's a good question I hadn't looked into yet.

Per https://w3c.github.io/navigation-timing/#marking-navigation-timing it's a straight up bug, but it's probably the responsibility of this effort to ensure test coverage which this issue can track.

Hopefully @bokand or @noamr is willing to file the bug but I can also do it if that would help.

noamr commented 1 year ago

It's a known Chrome bug that I totally forgot about when I went on parental leave :( https://bugs.chromium.org/p/chromium/issues/detail?id=1096983

See my comment 14: the current behavior is not according to spec: https://wicg.github.io/scroll-to-text-fragment/#processing-the-fragment-directive "The fragment directive is processed and removed from the fragment whenever the UA sets the URL on a Document."

The navigation timing name should be the same as the document URL. I will follow up from the Chrome side.

bokand commented 1 year ago

Yeah, I think, per-spec, the fragment directive shouldn't be exposed in navigation timing; that's a Chrome bug.

But I've heard in a couple of places that developers are using this (e.g. the chrome bug, twitter thread). It seems some found it useful to be able to add info to a URL that's guaranteed not to interfere with the page. Perhaps we could add an API to enable this use case in a structured way? See also https://github.com/WICG/scroll-to-text-fragment/issues/160#issuecomment-878373556

noamr commented 1 year ago

Yeah, I think, per-spec, the fragment directive shouldn't be exposed in navigation timing; that's a Chrome bug.

But I've heard in a couple of places that developers are using this (e.g. the chrome bug, twitter thread). It seems some found it useful to be able to add info to a URL that's guaranteed not to interfere with the page. Perhaps we could add an API to enable this use case in a structured way? See also #160 (comment)

Not sure this is great privacy-wise. I don't expect pages I navigate to via some text search to be able to tell what search term I used etc. The structured API to do this is perhaps standard query variables?

bokand commented 1 year ago

Not sure this is great privacy-wise.

The nice thing about providing a structured API is that we could, e.g., prevent exposing content for a sensitive directive like text, perhaps depending on conditions, cross/same origin, etc.. I believe the use case is to use a custom directive which would just pass through the content - I've asked on the Chrome bug for more information about usage.

(To be clear, the content in the text directive already exists on the page and a page could guess it, with some fuzziness, based on the scroll position. But point taken)

The structured API to do this is perhaps standard query variables?

Speculating but I think the fact that this will cause a new request, and include the parameters in the request, is probably the reason people were using the fragment. You'd also be relying on the server not choking on the unexpected query params.

noamr commented 1 year ago

In any case, to be clear, making this web-exposable would be a new conversation and performance.getEntries() should definitely not be the way to get this information.

noamr commented 1 year ago

See https://github.com/WICG/scroll-to-text-fragment/issues/128 for conversation about exposing text fragment to the page, with a lot of privacy-related conversation on the mozilla standards position. @annevk you were actually quite active on that one seems like :)

Apparently some existing content relies on the performance.getEntries() bug as a "feature" so the plot is a bit thicker.

annevk commented 1 year ago

The API questions should probably be discussed in their relevant issues. Resolving #217 might help with some of them as perhaps the Navigation API should be an entry point. What mainly concerns me about reading the fragment directive is consistency. It seems problematic that access to identifiers is conditional and might change in the future (e.g., if we decide another directive also needs to be hidden from script).