myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Klemens Schrage (JIRA)" <...@myfaces.apache.org>
Subject [jira] Issue Comment Edited: (TRINIDAD-952) In IE, cursor does not return to the correct component after PPR
Date Mon, 14 Sep 2009 12:41:58 GMT

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

Klemens Schrage edited comment on TRINIDAD-952 at 9/14/09 5:41 AM:
-------------------------------------------------------------------

We still see this problem in our environment. Would it be possible to "fake" the window.document.activeElement
in IE via an internal variable which is fed via onfocus handlers on every component? That
would always guaranty the correct component to be focused after the ppr has finished.

      was (Author: schragek):
    We still see problem in our environment. Would it be possible to "fake" the window.document.activeElement
in IE via an internal variable which is fed via onfocus handlers on every component? That
would always guaranty the correct component to be focused after the ppr has finished.
  
> 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
>            Assignee: Matthias We├čendorf
>            Priority: Minor
>             Fix For: 1.0.7-core, 1.2.7-core
>
>         Attachments: Trinidad11_952.patch, Trinidad12_952.patch
>
>   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.


Mime
View raw message