Does this make sense? It seems bad to return a failure when we potentially did modify things.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Looks good!
transactions;"transactions" is a bit funny. Maybe just `controls_to_fill` or something?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
"transactions" is a bit funny. Maybe just `controls_to_fill` or something?
Done.
Avoided this terminology except in the high-level description in the commit message.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
1 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: third_party/blink/renderer/core/html/forms/html_form_element.cc
Insertions: 5, Deletions: 5.
The diff is too large to show. Please review the diff.
```
[webmcp] Make FillFormControls transactional
Currently, it's possible for FillFormControls to return "false"
(failure), but still modify the form control states. This is assumed
to be undesirable behavior, and therefore this CL makes FillWebMCPData
transactional: We now validate the input first, and then "commit"
those changes as a whole once we're sure it is valid.
FillWebMCPData's capability of returning a bool is currently unused;
I've removed it for now, since any validation step needs to happen
separately in a transactional model.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |