ladybird/Tests/LibWeb/Text/input/scroll-during-page-load.html

<!DOCTYPE html>
<script src="include.js"></script>
<style>
div { height: 200vh; }
</style>
<div></div>
<script>
    window.scrollTo(0, 200);
    test(() => {
        println(`Scroll position: ${window.scrollY}px`);
    });
</script>
LibWeb: Respect scroll position set by script during page load When setting scroll position during page load we need to consider whether we actually have a fragment to scroll to. A script may already have run at that point and may already have set a scroll position. If there is an actual fragment to scroll to, it is fine to scroll to that fragment, since it should take precedence. If we don't have a fragment however, we should not unnecessarily overwrite the scroll position set by the script back to (0, 0). Since this problem is caused by a spec bug, I have tested the behavior in the three major browsers engines. Unfortunately they do not agree fully with each other. If there is no fragment at all (e.g. `foo.html`), all browsers will respect the scroll position set by the script. If there is a fragment (e.g. `foo.html#bar`), all browsers will set the scroll position to the fragment element and ignore the one set by script. However, when the fragment is empty (e.g. `foo.html#`), then Blink and WebKit will set scroll position to the fragment, while Gecko will set scroll position from script. Since all of this is ad-hoc behavior anyway, I simply implemented the Blink/WebKit behavior because of the majority vote for now. This fixes a regression introduced in 51102254b5. 2025-03-07 22:04:36 +01:00			`<!DOCTYPE html>`
			`<script src="include.js"></script>`
			`<style>`
			`div { height: 200vh; }`
			`</style>`
			`<div></div>`
			`<script>`
			`window.scrollTo(0, 200);`
			`test(() => {`
			println(`Scroll position: ${window.scrollY}px`);
			`});`
			`</script>`