Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <684701.1203017351665.JavaMail.jira@brutus>
Date: Thu, 14 Feb 2008 11:29:11 -0800 (PST)
From: "Yee-Wah Lee (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Commented: (TRINIDAD-952) In IE, cursor does not return to
 the correct component after PPR
In-Reply-To: <27197146.1203015188217.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/TRINIDAD-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569058#action_12569058 ] 

Yee-Wah Lee commented on TRINIDAD-952:
--------------------------------------

Propose adding a timeout to take the current thread off the queue, allowing the other thread that updates the cursor to run. Thus, when control returns to _pprStartBlocking() the browser's activeElement would be set to the next inputText element, and the sequence can proceed as normal.

> 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.