[
https://issues.apache.org/jira/browse/TRINIDAD-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569052#action_12569052
]
Yee-Wah Lee commented on TRINIDAD-952:
--------------------------------------
This is the sequence in IE:
- Before the partial form submit is triggered, _submitPartialChange calls
_pprStartBlocking() to block the UI while we are off on the server.
- On IE, _pprStartBlocking() figures out what element currently has the focus
(the activeElement), stores this information away in window._pprEventElement,
and then moves the focus to our event capture div. (This actually happens in
_pprControlCapture().)
- After the ppr response is applied, we restore the focus to the previously
focused element - ie. to the window._pprEventElement (or to the element with
the same id if the actual element has been replaced.)
In the cases above, the browser has the activeElement as the initial inputText,
even though the user has already tabbed off. So after the response is received,
the focus goes back to the initial inputText.
This is not a problem in Firefox because FF implements DOM level 2 which
provides support for event capture. So, there is no need to save the
activeElement and the above code path does not apply.
> In IE, cursor does not return to the correct component after PPR
> ----------------------------------------------------------------
>
> Key: TRINIDAD-952
> URL: https://issues.apache.org/jira/browse/TRINIDAD-952
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Environment: IE6 or IE7 browser
> Reporter: Yee-Wah Lee
> Priority: Minor
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> 1) Test cases #1
> TabFails.jspx
> <af:inputText label="Label 1"
> id="inputText1"
> binding="#{tabfails.inputText1}"
> autoSubmit="true"
> valueChangeListener="#{tabfails.doSomething1}"/>
> <af:inputText label="Label 2"
> id="inputText2"
> binding="#{tabfails.inputText2}"
> autoSubmit="true"/>
> <af:inputText label="Label 3"
> id="inputText3"
> binding="#{tabfails.inputText3}"
> autoSubmit="true"
> partialTriggers="inputText1"/>
> TabFails.java
> public void doSomething1(ValueChangeEvent valueChangeEvent) {
> String value1 = inputText1.getValue() == null ? null :
> inputText1.getValue().toString();
> String value2 = inputText2.getValue() == null ? null :
> inputText2.getValue().toString();
>
> inputText3.setSubmittedValue(null);
> inputText3.setValue(value1 + value2);
> }
> To reproduce the problem, click on inputText1 and modify its value then tab
> off. In FireFox, the value in InputText3 is updated and the cursor goes to
> InputText2 (as expected). In IE, the inputText3 is updated but the cursor
> goes back to inputText1.
> 2) Test case #2.
> <af:inputText label="Label 4" autoSubmit="true"
> binding="#{tabfails.inputText4}" simple="true"/>
> <af:inputText label="Label 5" autoSubmit="true"
> binding="#{tabfails.inputText5}" simple="true"/>
> <af:inputText label="Label 6" autoSubmit="true"
> binding="#{tabfails.inputText6}" simple="true"/>
> To reproduce the problem, click on inputText4 and modify its value then tab
> off. In FireFox, the value in InputText4 is updated and the cursor goes to
> InputText5 (as expected). In IE, the inputText4 is updated but the cursor
> goes back to inputText4.
> Both cases involve PPR and the javascript to restore the active element in
> IE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
