tree dc75461f39e56e12a29d517c669bf9c7b0d21be1
parent 1b30f748f57009fa3dcb9e3037cee242dbc7934e
author wenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1585854406 +0000
committer wenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1585854406 +0000

Avoid null deref after inserting a text field with a list attribute
https://bugs.webkit.org/show_bug.cgi?id=209909
<rdar://problem/60742229>

Reviewed by Ryosuke Niwa.

Source/WebCore:

On macOS, when painting a text field with an associated datalist (i.e. `HTMLInputElement::list()` is non-null),
we assume that the datalist suggestions dropdown button has a renderer (in other words, it does not have a style
of `display: none`).

Existing logic in `TextFieldInputType` is responsible for upholding this invariant -- when the list attribute
changes on an input field (e.g. when we parse the list attribute, or when it is set by JavaScript), we update
the inline display style of `m_dataListDropdownIndicator`, such that it is set to `display: none` only if there
is either no list attribute, or the list attribute is empty, or the list does not refer to a connected datalist
element. However, there is one scenario in which this invariant is violated. Consider the following:

1. An input field is created, and its list attribute is set to "foo". Importantly, it is not connected yet.
2. A datalist element with id "foo" is then created and then added to the document.
3. The input field created in (1) is then added to the document.

In this scenario, `listAttributeTargetChanged()` is invoked after (1), but since it is not connected, it has no
datalist yet, and so `m_dataListDropdownIndicator` will remain non-rendered. When it is later added to the DOM,
nothing attempts to `m_dataListDropdownIndicator` even though its list attribute now refers to a datalist, so
it remains hidden. When we later go to paint the input's datalist dropdown button in
`RenderThemeMac::paintListButtonForInput`, we assume that the dropdown button must be rendered because the input
has a datalist and subsequently crash since `buttonElement->renderer()` remains null.

To fix this, we add logic to update the datalist dropdown button's inline display style when it is connected to
the document with an existing, non-empty list attribute.

Test: fast/forms/datalist/append-input-with-list-attribute.html

* html/HTMLInputElement.cpp:
(WebCore::HTMLInputElement::parseAttribute):
(WebCore::HTMLInputElement::didFinishInsertingNode):

Notify the InputType subclass that the datalist element may have changed after an input element is connected
to the document with a non-empty list attribute.

(WebCore::HTMLInputElement::dataListMayHaveChanged):
(WebCore::ListAttributeTargetObserver::idTargetChanged):
(WebCore::HTMLInputElement::listAttributeTargetChanged): Deleted.

Rename listAttributeTargetChanged to dataListMayHaveChanged, since it is no longer called only when the list
attribute changes value, but rather when the input's datalist element may have changed.

* html/HTMLInputElement.h:
* html/InputType.cpp:
(WebCore::InputType::dataListMayHaveChanged):
(WebCore::InputType::listAttributeTargetChanged): Deleted.
* html/InputType.h:
* html/RangeInputType.cpp:
(WebCore::RangeInputType::dataListMayHaveChanged):
(WebCore::RangeInputType::listAttributeTargetChanged): Deleted.
* html/RangeInputType.h:
* html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::dataListMayHaveChanged):
(WebCore::TextFieldInputType::listAttributeTargetChanged): Deleted.
* html/TextFieldInputType.h:

LayoutTests:

Add a layout test to exercise the crashing scenario, and verify that the end result of programmatically
inserting the text field is identical to simply putting an input field with a datalist in the markup.

* fast/forms/datalist/append-input-with-list-attribute-expected.html: Added.
* fast/forms/datalist/append-input-with-list-attribute.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@259402 268f45cc-cd09-0410-ab3c-d52691b4dbfc