mirror of
https://github.com/LadybirdBrowser/ladybird
synced 2026-04-25 17:25: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
38 lines
952 B
HTML
38 lines
952 B
HTML
<!DOCTYPE html>
|
|
<style>
|
|
textarea {
|
|
font-size: 16px;
|
|
width: 100px;
|
|
height: 1.5em;
|
|
padding: 2px;
|
|
border: 1px solid;
|
|
resize: none;
|
|
white-space: nowrap;
|
|
}
|
|
div[contenteditable] {
|
|
font-size: 16px;
|
|
width: 100px;
|
|
height: 1.5em;
|
|
overflow: auto;
|
|
white-space: nowrap;
|
|
}
|
|
</style>
|
|
<textarea>foobarbazloremipsum foobarbazloremipsum</textarea>
|
|
<div contenteditable>foobarbazloremipsum foobarbazloremipsum</div>
|
|
<script src="include.js"></script>
|
|
<script>
|
|
test(() => {
|
|
const textarea = document.querySelector("textarea");
|
|
const div = document.querySelector("div[contenteditable]");
|
|
textarea.offsetWidth;
|
|
|
|
textarea.focus();
|
|
internals.sendKey(textarea, "End");
|
|
println(`textarea scrollLeft: ${textarea.scrollLeft}`);
|
|
|
|
div.focus();
|
|
internals.sendKey(div, "End");
|
|
println(`div scrollLeft: ${div.scrollLeft}`);
|
|
});
|
|
</script>
|