Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.0
-
Fix Version/s: EE-4.0.0.GA, 4.1
-
Component/s: Sample Apps
-
Labels:None
-
Environment:Tomcat 7, ICEfaces EE-4.0.0 Jenkins build 4, IE 8 only
-
Assignee Priority:P1
Description
textAreaEntry > Indicator text, requiredStyling (IE 8 only)
Clicking on the Comments panel (not within the textAreaEntry component), then pressing Enter causes a console error. After error appears page can no longer be interacted with and must be refreshed.
Noticed that this is occurring with all input comps that are inside a panel. Showcase demos affected include autoCompleteEntry, dateTimeEntry, maskedEntry, textAreaEntry, textEntry, simpleSelectOneMenu... possibly others
Message: Invalid argument.
Line: 1
Char: 31496
Code: 0
URI: http://localhost:8080/showcase/javax.faces.resource/jsf.js.jsf?ln=javax.faces&v=4_0_0_150331
To reproduce:
1.) Launch showcase using IE 8.
2.) Navigate to ace:textAreaEntry > Indicator Text
3.) DO NOT place focus into the textAreaEntry
4.) Click anywhere inside the panel where the textAreaEntry resides (but not in the textAreaEntry)
5.) Press Enter, console error appears.
Clicking on the Comments panel (not within the textAreaEntry component), then pressing Enter causes a console error. After error appears page can no longer be interacted with and must be refreshed.
Noticed that this is occurring with all input comps that are inside a panel. Showcase demos affected include autoCompleteEntry, dateTimeEntry, maskedEntry, textAreaEntry, textEntry, simpleSelectOneMenu... possibly others
Message: Invalid argument.
Line: 1
Char: 31496
Code: 0
URI: http://localhost:8080/showcase/javax.faces.resource/jsf.js.jsf?ln=javax.faces&v=4_0_0_150331
To reproduce:
1.) Launch showcase using IE 8.
2.) Navigate to ace:textAreaEntry > Indicator Text
3.) DO NOT place focus into the textAreaEntry
4.) Click anywhere inside the panel where the textAreaEntry resides (but not in the textAreaEntry)
5.) Press Enter, console error appears.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
It seems that IE8 will fire keydown events for TD elements, something that the other browsers do not do.
The fix modifies ice.captureKeypress to issue a submit only when the capturing element has an ID attribute defined. This avoids submitting elements that were not intended for triggering an action on the server (instead of just blocking TD from firing keydown events that in some other cases might be desired).
Show
Mircea Toma
added a comment - It seems that IE8 will fire keydown events for TD elements, something that the other browsers do not do.
The fix modifies ice.captureKeypress to issue a submit only when the capturing element has an ID attribute defined. This avoids submitting elements that were not intended for triggering an action on the server (instead of just blocking TD from firing keydown events that in some other cases might be desired).
Verified ICEfaces EE-4.0.0 Jenkins build 6. Tomcat 7, IE 8.
Show
Liana Munroe
added a comment - Verified ICEfaces EE-4.0.0 Jenkins build 6. Tomcat 7, IE 8.
This is actually a more general problem in the bridge. The problem is not specific to input components or to ace:panel; it affects <table> elements in general (and its subelements). The issue is seen in this kind of demos, because it turns out that all those ace:panel's contain an h:panelGrid component (which renders a table element) to arrange the input components inside. The issue occurs when clicking on any area of a table and then pressing the enter key. The issue can also be reproduced on the ace:panel > Overview demo, which doesn't contain any input components but it contains an h:panelGrid. The rest of the ace:panel demos don't contain h:panelGrid's so the issue is not present there. The issue can be reproduced on all ace:dataTable demos as well.
The root cause of this is the 'captureKeypress' function in the capture-submit.js source file in the core folder, which is triggered when pressing the enter key on a table or table cell. It seems like the capture submit functionality is being applied to tables or table cells on IE8. I added some debugging code to that function and could see that the source element was always a table cell when this issue occurred.