Don't invoke text fragment anchors until the document has parsed or loaded.
Text fragment anchors are very expensive to compute; otherwise page load performance may suffer significantly. Before this CL, text fragments could be invoked an arbitrary number of times up to the time when the document was loaded - whenever a lifecycle-based or forced update happened. This slowed down page load, as well as all layout-inducing DOM APIs. A previous CL (*) regressed performance on top of this problem, because it invoked the text fragment regardless of whether layout was dirty. Before that CL, the expensive part of text fragment invocation only happened if layout was dirty. Layout could be dirty many times before the document is loaded, but many fewer times than the number of lifecycles or forced layouts. The main consequence of this CL is that text fragment invocation will not happen at all until the document is parsed, and then once again once it is loaded (which includes waiting for certain subresources to load, in particular images). It appears that the spec allows (*) user agents to define the timing of fragment scrolling and highlighting. The test TextFragmentAnchorTest.TargetStaysInView exercises this new code code quite well, and still passes with this CL. I couldn't make it pass until every part of the new CL was in place. (*) https://chromium-review.googlesource.com/c/chromium/src/+/1981806 (**) https://html.spec.whatwg.org/multipage/browsing-the-web.html#try-to-scroll-to-the-fragment Bug: 1094452 Change-Id: Iee19989061128ff158b72ed99cabd0dec8f449e1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2267137Reviewed-by:David Bokan <bokan@chromium.org> Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#782814}
Showing
Please register or sign in to comment