whatwg
(scroll-to-text) Allow limiting the number of scroll fragments
What is the issue with the HTML Standard?
(The PR for this feature is being upstreamed here https://github.com/whatwg/html/pull/11895)
Currently the number of specified scroll fragments could be theoretically unbounded (limited I guess only by the length of the url string).
Similar to #11938, in order to limit the amount of work that a user-agent has to do in response, I propose we allow the user-agent to limit the number of fragments processed. I don't know if there's any particular specific number that works best, so perhaps leaving this up to user-agent discretion. In practice, in Chromium we'd like to try and limit this to something like 100 which should be plenty for most cases (famous last words, I know).
@domfarolino @annevk @bokand
Given that the amount of work depends on the size of the document (and the complexity of the text fragment and its use of context terms), I am not sure if limiting to an arbitrary amount of text fragments is a good idea. This link, which has 5 text directives at the end of the page, is going to need a lot longer to load than this one, which contains 10 text fragments at the beginning of the same page.
Since searching for text fragments is done synchronously, this could be used to create links that make web pages unresponsive or crash (I think a while ago I had created a text fragment link to the HTML spec page which took ~15 minutes to load in Chrome and Safari due to quadratic behavior in the spec). I wonder if instead proposing an (user-agent defined) timeout is a better idea. Stop searching for text fragments after X seconds and then only show the ones which were found. The (theoretical) downside to this is that this makes the visual result for the end user dependent on the user's device, which is not great.
This also makes me wonder if searching for text fragments synchronously during page load is the best idea, but I'm not sure if I want to open that can of worms.
cc @zcorpan
I think a timeout idea would work to solve this as well. I agree with you that there may be better architectural solutions (async searching) but I don't intend this issue to redesign how the whole feature works, simply to put a bound on the amount of work that we are required to do.