[
https://issues.apache.org/jira/browse/TAP5-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567948#comment-14567948
]
Hudson commented on TAP5-2480:
------------------------------
ABORTED: Integrated in tapestry-trunk-freestyle #1436 (See
[https://builds.apache.org/job/tapestry-trunk-freestyle/1436/])
TAP5-2480: HTML5 vs. Form Fragment, in Chrome (hlship: rev
6e1ebb30ce572efde8cb6ebc83f5ca46f80a04e7)
*
tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/FormFragment.java
*
tapestry-core/src/main/coffeescript/META-INF/modules/t5/core/form-fragment.coffee
> 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)