[
https://issues.apache.org/jira/browse/TAP5-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567654#comment-14567654
]
ASF subversion and git services commented on TAP5-2480:
-------------------------------------------------------
Commit 6e1ebb30ce572efde8cb6ebc83f5ca46f80a04e7 in tapestry-5's branch
refs/heads/master from [~hlship]
[ https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;h=6e1ebb3 ]
TAP5-2480: HTML5 vs. Form Fragment, in Chrome
This changes FormFragment to disable all input fields inside the fragment when
it is hidden (including if it is hidden
on initial render). When the fragment is shown, it finds the hidden fields and
enables them.
> FormFragment can't be used in conjunction with HTML5 support
> ------------------------------------------------------------
>
> Key: TAP5-2480
> URL: https://issues.apache.org/jira/browse/TAP5-2480
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.4
> Reporter: I D
> Assignee: Howard M. Lewis Ship
> Fix For: 5.4
>
>
> Steps to reproduce:
> # Use Chrome
> # Set SymbolConstants.ENABLE_HTML5_SUPPORT to true
> # Have a page with a form containing a FormFragment containing a field with
> the "required" validator
> # Hide the FormFragment
> # Attempt to submit the form
> # Note that nothing happens and the following JS error appears in the Chrome
> dev tools console: "An invalid form control with name='whatever' is not
> focusable."
> This is due to the fact that when SymbolConstants.ENABLE_HTML5_SUPPORT is set
> to true, the "required" validator adds a "required" attribute to the form
> field, which in turn makes the browser want to validate it.
> At first I thought this could be fixed simply by a slight modification:
> whenever a form fragment handles the prepareForSubmit event and sets the
> fragment's hidden element's "disabled" attribute, it should also set the
> "disabled" attributes of all inputs, selects, textareas etc contained therein
> to the same value. This will disable native browser validation for these
> fields.
> However, I then realized that the prepareForSubmit event isn't even triggered
> by the browser in this case.
> This means that we shouldn't even rely on the prepareForSubmit event here,
> and instead set the disabled attribute (in the generated hidden field as well
> as the actual ones) whenever the "events.formfragment.changeVisibility" is
> triggered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
