mirror of
https://github.com/LadybirdBrowser/ladybird
synced 2026-04-26 01:35:08 +02:00
ded42e649b
We were mimicking Firefox' behavior that whenever a programmatic change to an <input>'s or <textarea>'s selection happened, the new selection focus is brought into view by scrolling. Currently we run a layout update synchronously for that to make sure we have the fragment's correct dimensions, which caused a significant performance regression in Speedometer. Since this is non-standard behavior, let's mimic Chromium instead which does not scroll at all - only for direct user initiated input such as typing. Relevant issues: * https://github.com/whatwg/html/issues/6217 * https://bugzilla.mozilla.org/show_bug.cgi?id=232405 * https://issues.chromium.org/issues/41081857
33 lines
913 B
HTML
33 lines
913 B
HTML
<!DOCTYPE html>
|
|
<style>
|
|
input {
|
|
font-size: 16px;
|
|
width: 100px;
|
|
padding: 2px;
|
|
border: 1px solid;
|
|
}
|
|
</style>
|
|
<input value="foobarbazloremipsum foobarbazloremipsum" />
|
|
<script src="include.js"></script>
|
|
<script>
|
|
test(() => {
|
|
const input = document.querySelector("input");
|
|
input.offsetWidth;
|
|
input.focus();
|
|
|
|
// Click near the left edge before scrolling.
|
|
const rect = input.getBoundingClientRect();
|
|
const x = rect.left + 5;
|
|
const y = rect.top + rect.height / 2;
|
|
internals.click(x, y);
|
|
println(`before: ${input.selectionStart}`);
|
|
|
|
// Move cursor to the end via keyboard, which should scroll the input.
|
|
internals.sendKey(input, "End");
|
|
|
|
// Click in the same spot after scrolling.
|
|
internals.click(x, y);
|
|
println(`after: ${input.selectionStart}`);
|
|
});
|
|
</script>
|