Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: c1628ee675b75f07c8f727628d5fefeb5df200d7
https://github.com/WebKit/WebKit/commit/c1628ee675b75f07c8f727628d5fefeb5df200d7
Author: Chris Dumez <[email protected]>
Date: 2023-04-19 (Wed, 19 Apr 2023)
Changed paths:
M Source/WebCore/html/HTMLInputElement.cpp
M Source/WebCore/html/NumberInputType.cpp
Log Message:
-----------
Early return in HTMLInputElement::attributeChanged() when the attribute value
hasn't changed
https://bugs.webkit.org/show_bug.cgi?id=255617
Reviewed by Ryosuke Niwa.
Early return at the beginning of HTMLInputElement::attributeChanged() if the new
attribute value is the same as the old one. HTMLInputElements do not have
special
handling when setting an attribute to the same value again so they can ignore
this
case.
* Source/WebCore/html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::attributeChanged):
* Source/WebCore/html/NumberInputType.cpp:
(WebCore::NumberInputType::attributeChanged):
Make sure we call setNeedsLayoutAndPrefWidthsRecalc() if the class attribute
changes. The bug was caught by fast/forms/number/number-size.html. We were
previously getting lucky. The test was changing the class attribute of a
number input element, then setting min/max attributes to the same value
and expecting the borders of the input element to change. It would previously
work because setting min/max would call setNeedsLayoutAndPrefWidthsRecalc()
even when set to the same value. However, what's really changing here
and requires a new layout is the class attribute.
Canonical link: https://commits.webkit.org/263151@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
