Control value is not updated after dynamic changes to color input or textarea, meaning AX clients get stale data.
<rdar://problem/103331337>
Created attachment 464032 [details] Patch
rdar://103272091
Created attachment 464035 [details] Patch
(In reply to Tyler Wilcock from comment #4) > Created attachment 464035 [details] > Patch I would remove the prefix "dynamic" from the name of these tests, they already have "changes" in their names. It makes it easier to group them by element name if the name is just color-input-value-changes.html, for instance. diff --git a/LayoutTests/accessibility/dynamic-color-input-value-changes.html b/LayoutTests/accessibility/dynamic-color-input-value-changes.html new file mode 100644 index 000000000000..31566c4c27cc --- /dev/null +++ b/LayoutTests/accessibility/dynamic-color-input-value-changes.html + // There are a few layouts that happen when the page loads — use this `sleep` to wait them out before changing + // the color value. If we change the color value before these layouts occur, we pass the test no matter + // what (even if our implementation is wrong). This is because a top-level children changed notification causes + // the color input AX object to be re-built with the correct value, making us pass the test on accident. + await sleep(60); Can we put the color change in onload instead? Or listen for the layout changed notifications and do it after them? Concern that this would make it flaky cause it is not deterministic with a fix time elapse . Same for the other two tests.
Created attachment 464046 [details] Patch
(In reply to Tyler Wilcock from comment #6) > Created attachment 464046 [details] > Patch Looks great, thanks! The commit message lists the test files with the old names * LayoutTests/accessibility/dynamic-color-input-value-changes-expected.txt: Added. ... cause the scripts don't update this reliably. In some cases I delete that section altogether because it gets out of sync easily with your changes and it is not easy to fix manually. Don't know if there is a good way of updating that. There was some talk in the dev mailing list to remove the section completely. You may fix it in this case with git commit --amend, but not big deal, no need to R? again, just CQ+.
Created attachment 464057 [details] Patch
Committed 257976@main (40bfa0c8714b): <https://commits.webkit.org/257976@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 464057 [details].