[webkit-changes] [WebKit/WebKit] c1628e: Early return in HTMLInputElement::attributeChanged...

[Chris Dumez]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: c1628ee675b75f07c8f727628d5fefeb5df200d7
      https://github.com/WebKit/WebKit/commit/c1628ee675b75f07c8f727628d5fefeb5df200d7
  Author: Chris Dumez <cdumez at apple.com>
  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