ICEfaces
  1. ICEfaces
  2. ICE-4401

selectInputDate , tabbing between mutiple selectiputdateComponents is broken in IE.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.2 SP1, 1.8
    • Fix Version/s: 1.8.1
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      tomcat 6, icefaces 1.8 or 1.72sp , internet explorer 7
    • Workaround Exists:
      Yes
    • Workaround Description:
      partial , but not a complete solution, force tabindex values to 0, selectInputDate.setTabindex(0), in the selectInputdateRender class.Still research impacts elsewhere of workaround. (more in comments

      Description

      When multiple selectinputdate components exist on a form (see screen print) and partialSubmit is true and TABINDEX is not set on anything.

      After the return from the partialSubmit (triggered by the valuechangeListener), focus goes to the address bar or menu if present , should go to the second selectinputdate. This is similar to the behavoir described in ice-3938 which indicated fixed in 1.8. That code doesn't even execute unless a tabindex is set on each component.
      1. element.js
        21 kB
        Michelle Cannon
      2. element.js
        21 kB
        Michelle Cannon
      3. icefaces-d2d.js
        83 kB
        Michelle Cannon
      4. icefaces-d2d.js
        83 kB
        Michelle Cannon
      1. screenshot-1.jpg
        106 kB

        Issue Links

          Activity

          Hide
          Michelle Cannon added a comment -

          the code fix for ice-3938 doesn't even execute if tabindex is not set, focus gets lost after the partialsubmit.

          The workaround is to set the tabindex to a 0 value when the component is rendered.

          Show
          Michelle Cannon added a comment - the code fix for ice-3938 doesn't even execute if tabindex is not set, focus gets lost after the partialsubmit. The workaround is to set the tabindex to a 0 value when the component is rendered.
          Hide
          Michelle Cannon added a comment -

          put 4/24/2009 in the first selectinputdate, this will trigger the valuechangelistener, on ie7 focus goes to the address bar , it should go to the next selectinputdate

          Show
          Michelle Cannon added a comment - put 4/24/2009 in the first selectinputdate, this will trigger the valuechangelistener, on ie7 focus goes to the address bar , it should go to the next selectinputdate
          Hide
          Michelle Cannon added a comment -

          workaround

          1.8, version 18727 at line 302

          int idx = 0;
          if( selectInputDate.getTabindex() == null ){

          selectInputDate.setTabindex(""+idx);

          A better solution is to add tabindex to all input components initially, However that may not work for all users.
          A simple script exeucted from dombasicrenderer or just walking the dom from the form to the component may work

          Show
          Michelle Cannon added a comment - workaround 1.8, version 18727 at line 302 int idx = 0; if( selectInputDate.getTabindex() == null ){ selectInputDate.setTabindex(""+idx); A better solution is to add tabindex to all input components initially, However that may not work for all users. A simple script exeucted from dombasicrenderer or just walking the dom from the form to the component may work
          Hide
          Michelle Cannon added a comment -

          More testing this morning. The bug does occur in ie6 too.

          Seems to have something to do with valuechangelistener. The above workaround only works on the simplest forms.

          Show
          Michelle Cannon added a comment - More testing this morning. The bug does occur in ie6 too. Seems to have something to do with valuechangelistener. The above workaround only works on the simplest forms.
          Hide
          Michelle Cannon added a comment - - edited

          attached modified element.js and bridge js.
          Changes to element .js seem to have caused the focus issue.
          These have not undergone full regression testing, need to access if any impact with other components on the screen.

          Show
          Michelle Cannon added a comment - - edited attached modified element.js and bridge js. Changes to element .js seem to have caused the focus issue. These have not undergone full regression testing, need to access if any impact with other components on the screen.
          Hide
          Michelle Cannon added a comment -
          Show
          Michelle Cannon added a comment - created forum post http://www.icefaces.org/JForum/posts/list/12637.page
          Hide
          Michelle Cannon added a comment -

          My original fix to the bridge, caused problem with the panelseries , the corrected files are attached.

          Show
          Michelle Cannon added a comment - My original fix to the bridge, caused problem with the panelseries , the corrected files are attached.
          Hide
          Michelle Cannon added a comment -

          corrected, testing showed earlier fix had issue with panel grid.

          Show
          Michelle Cannon added a comment - corrected, testing showed earlier fix had issue with panel grid.
          Hide
          Marcel Groeneweg added a comment -

          ICEfaces team, this is a show stopper to us.
          Our customers and end users will not accept focus issues, as this leads to poor data entry performance:
          Grabbing the mouse, finding the cursor on screen, positioning the cursor, clicking somewhere, then continue with work.

          Please fix this issue with the upcoming 1.8.1 release!

          Show
          Marcel Groeneweg added a comment - ICEfaces team, this is a show stopper to us. Our customers and end users will not accept focus issues, as this leads to poor data entry performance: Grabbing the mouse, finding the cursor on screen, positioning the cursor, clicking somewhere, then continue with work. Please fix this issue with the upcoming 1.8.1 release!
          Hide
          Mircea Toma added a comment -

          I could not reproduce the issue described here. Also, there is no difference in behavior between 1.7.1, 1.8 and Trunk.

          In IE7 changing the date in the input field and then pressing Tab will move the focus on the image button used to open the popup calendar, pressing the Tab again will move the focus to the input field of the next 'selectInputDate' entry as expected. In Firefox the focus will move the focus directly to the next input field (known Firefox behavior to skip focusing anchor elements when tabbing).

          The only way I could make the focus to get lost was only when two or more 'selectInputDate' instances found in the page where wired to the same value binding.
          If we decide to add support for 'selectInputDate' instances bound the same binding then we can re-open this issue or create a new one describing better the required feature.

          Show
          Mircea Toma added a comment - I could not reproduce the issue described here. Also, there is no difference in behavior between 1.7.1, 1.8 and Trunk. In IE7 changing the date in the input field and then pressing Tab will move the focus on the image button used to open the popup calendar, pressing the Tab again will move the focus to the input field of the next 'selectInputDate' entry as expected. In Firefox the focus will move the focus directly to the next input field (known Firefox behavior to skip focusing anchor elements when tabbing). The only way I could make the focus to get lost was only when two or more 'selectInputDate' instances found in the page where wired to the same value binding. If we decide to add support for 'selectInputDate' instances bound the same binding then we can re-open this issue or create a new one describing better the required feature.
          Hide
          Marcel Groeneweg added a comment -

          That is not my experience, after pressing tab on the input part of the date, focus moves to the button. Pressing tab causes focus to be lost i.s.o. moving to the next input component. Please re-open this issue.

          Show
          Marcel Groeneweg added a comment - That is not my experience, after pressing tab on the input part of the date, focus moves to the button. Pressing tab causes focus to be lost i.s.o. moving to the next input component. Please re-open this issue.
          Hide
          Mircea Toma added a comment -

          Marcel, can you provide a test case that will help us reproduce what you are seeing? Are the 'selectInputDate' components wired to the same value binding?

          Show
          Mircea Toma added a comment - Marcel, can you provide a test case that will help us reproduce what you are seeing? Are the 'selectInputDate' components wired to the same value binding?
          Hide
          Mircea Toma added a comment -

          Just to explain better, since 1.7.2SP1 and 1.8 when 'input' elements are
          updated they are replaced with new elements while before they used to be
          just edited. If the 'input' element had focus the update will make it
          loose the focus because the old 'input' element is replaced in the
          document (this occurs only in IE). Reverting back to old behavior, how
          the reporter of the issue suggests, is not the right solution in my
          opinion. Most of the elements when updated are replaced with new ones,
          they loose the focus too but the component renderers are aware of this
          behavior thus having to manage/mantain the focus.

          When two or more 'selectInputDate' instances are wired to the same value
          binding they generate updates for their 'input' elements. This causes
          the focus to be lost. If we care to support this use case then I would
          recommend to modify the renderer to manage the focus properly.

          Show
          Mircea Toma added a comment - Just to explain better, since 1.7.2SP1 and 1.8 when 'input' elements are updated they are replaced with new elements while before they used to be just edited. If the 'input' element had focus the update will make it loose the focus because the old 'input' element is replaced in the document (this occurs only in IE). Reverting back to old behavior, how the reporter of the issue suggests, is not the right solution in my opinion. Most of the elements when updated are replaced with new ones, they loose the focus too but the component renderers are aware of this behavior thus having to manage/mantain the focus. When two or more 'selectInputDate' instances are wired to the same value binding they generate updates for their 'input' elements. This causes the focus to be lost. If we care to support this use case then I would recommend to modify the renderer to manage the focus properly.
          Hide
          Marcel Groeneweg added a comment -

          I will post a test case. A simple test works fine so reproducing it will take a little time.

          Show
          Marcel Groeneweg added a comment - I will post a test case. A simple test works fine so reproducing it will take a little time.
          Hide
          Michelle Cannon added a comment -

          I have attached a test case, most of what you state above is invalid. because the test case has only a single selectinputdate component on it and only a single value change listener (not on the component), this is a valid instance.
          The behavior in firefox and safari is that after entering a date focus goes to the next field.
          The behavior in ie7 is focus goes to the first field the inputtext.
          The behavior in i7 with my change is focus goes to the next field after the selectinputdate (expected behavior)

          The fact that this is a very simple situation to reproduce leads me to question the rest of your analysis. I can fully understand why the changes made to the bridge would case the issues were seeing, I'm not exactly sure why your QA is missing this.

          Show
          Michelle Cannon added a comment - I have attached a test case, most of what you state above is invalid. because the test case has only a single selectinputdate component on it and only a single value change listener (not on the component), this is a valid instance. The behavior in firefox and safari is that after entering a date focus goes to the next field. The behavior in ie7 is focus goes to the first field the inputtext. The behavior in i7 with my change is focus goes to the next field after the selectinputdate (expected behavior) The fact that this is a very simple situation to reproduce leads me to question the rest of your analysis. I can fully understand why the changes made to the bridge would case the issues were seeing, I'm not exactly sure why your QA is missing this.
          Hide
          Michelle Cannon added a comment -

          this is a very simple test case with one selectinputdate, no jars to reduce size. build file, you may need to modify because it was built with myeclipse.

          Show
          Michelle Cannon added a comment - this is a very simple test case with one selectinputdate, no jars to reduce size. build file, you may need to modify because it was built with myeclipse.
          Hide
          Mircea Toma added a comment -

          Can you describe the steps I need go through to reproduce the issue?
          It is not clear to me if just tabbing through the fields is enough or do I have to edit the date, do I have to press Enter or should I tab out .....
          I can re-open the issue and pursue a fix but I need to replicate what you are seeing.

          Show
          Mircea Toma added a comment - Can you describe the steps I need go through to reproduce the issue? It is not clear to me if just tabbing through the fields is enough or do I have to edit the date, do I have to press Enter or should I tab out ..... I can re-open the issue and pursue a fix but I need to replicate what you are seeing.
          Hide
          Marcel Groeneweg added a comment -

          The selectInputdate did not have a partialSubmit attribute.
          Explicitly setting partialSubmit="false" solved the issue.
          I do not want partial submit on detail panel elements, I expected not setting partialSubmit would default it to false.
          Besides that, tabbing should work correctly with partial submit too.

          Show
          Marcel Groeneweg added a comment - The selectInputdate did not have a partialSubmit attribute. Explicitly setting partialSubmit="false" solved the issue. I do not want partial submit on detail panel elements, I expected not setting partialSubmit would default it to false. Besides that, tabbing should work correctly with partial submit too.
          Hide
          Ken Fyten added a comment -

          Re-opened. Mircea let me know if you think the comp. team should look into this now.

          Show
          Ken Fyten added a comment - Re-opened. Mircea let me know if you think the comp. team should look into this now.
          Hide
          Mircea Toma added a comment -

          Yes, comp. team should take a look at how to maintain focus on the updated 'input' element that is rendered by 'selectInputDate'. Since 1.7.2SP1/1.8 'input' elements are updated just like the rest of element types that can receive focus (such as 'select', 'a', 'textarea' and 'button').

          Show
          Mircea Toma added a comment - Yes, comp. team should take a look at how to maintain focus on the updated 'input' element that is rendered by 'selectInputDate'. Since 1.7.2SP1/1.8 'input' elements are updated just like the rest of element types that can receive focus (such as 'select', 'a', 'textarea' and 'button').
          Hide
          Adnan Durrani added a comment -

          I have tested the attached test case with 1.8 and trunk under IE6 and IE8, but didn't see any problem.
          Scenario 1:

          • tab on inputText, focus goes to selectInputText.
          • selecting date on the popup calendar, focus goes to the close button.
          • tab on close button, focus goes to next inputText.

          Scenario 2:

          • enter date to the calendar input filed, hit enter, focus stays to the input field.
          • tab on calendar input filed, focus goes to close button.
          • tab on close button, focus goes to next inputText.
          Show
          Adnan Durrani added a comment - I have tested the attached test case with 1.8 and trunk under IE6 and IE8, but didn't see any problem. Scenario 1: tab on inputText, focus goes to selectInputText. selecting date on the popup calendar, focus goes to the close button. tab on close button, focus goes to next inputText. Scenario 2: enter date to the calendar input filed, hit enter, focus stays to the input field. tab on calendar input filed, focus goes to close button. tab on close button, focus goes to next inputText.
          Hide
          Marcel Groeneweg added a comment -

          And tabbing past the selectInputDate without making any changes or clicking?

          That's how I first ran into the issue: The default value would normally be OK for the panel I was working on and I tested tabbing past the date to type into the inputText elements below the selectInputDate.

          Show
          Marcel Groeneweg added a comment - And tabbing past the selectInputDate without making any changes or clicking? That's how I first ran into the issue: The default value would normally be OK for the panel I was working on and I tested tabbing past the date to type into the inputText elements below the selectInputDate.
          Hide
          Michelle Cannon added a comment - - edited

          <quote I have tested the attached test case with 1.8 and trunk under IE6 and IE8, but didn't see any problem. >

          Note that all the failed test cases refer to ie7 so why was tested confined to ie6 and ie8.

          Most corp customers will be using ie6 or ie7.

          Ie8 is very new, and has a changed document object model. so you can't say that ie8 is an incremental improvement over ie7. Why wasn't ie7 included in your testing.

          Show
          Michelle Cannon added a comment - - edited <quote I have tested the attached test case with 1.8 and trunk under IE6 and IE8, but didn't see any problem. > Note that all the failed test cases refer to ie7 so why was tested confined to ie6 and ie8. Most corp customers will be using ie6 or ie7. Ie8 is very new, and has a changed document object model. so you can't say that ie8 is an incremental improvement over ie7. Why wasn't ie7 included in your testing.
          Hide
          Adnan Durrani added a comment - - edited

          It was tested under IE8 with compatibility view on. That should cover it.

          Show
          Adnan Durrani added a comment - - edited It was tested under IE8 with compatibility view on. That should cover it.
          Hide
          Marcel Groeneweg added a comment -

          <quote It was tested under IE8 with compatibility view on. That should cover it. >

          Personally I do not trust that IE8 in compatibity view is 100% the same as IE7.
          Just google IE8 compatibility view and you will find that it's not just an IE7 engine piggybacking on IE8.

          As Michelle stated, IE8 is way too new to be used in corporate environments.
          We have IE7, but many of our customers still have IE6.
          Please test on IE7 as well.

          We're not badgering you guys for nothing!

          Show
          Marcel Groeneweg added a comment - <quote It was tested under IE8 with compatibility view on. That should cover it. > Personally I do not trust that IE8 in compatibity view is 100% the same as IE7. Just google IE8 compatibility view and you will find that it's not just an IE7 engine piggybacking on IE8. As Michelle stated, IE8 is way too new to be used in corporate environments. We have IE7, but many of our customers still have IE6. Please test on IE7 as well. We're not badgering you guys for nothing!
          Hide
          Adnan Durrani added a comment - - edited

          Marcel I have attached ICE-4401.war, using ICEFaces 1.8 and source code provided by you. I am going to send this war to the QA to test with IE 7.

          Show
          Adnan Durrani added a comment - - edited Marcel I have attached ICE-4401 .war, using ICEFaces 1.8 and source code provided by you. I am going to send this war to the QA to test with IE 7.
          Hide
          Marcel Groeneweg added a comment -

          Great! I hope QA can reproduce the issue.
          BTW Michelle provided the test case and other fixes.

          Show
          Marcel Groeneweg added a comment - Great! I hope QA can reproduce the issue. BTW Michelle provided the test case and other fixes.
          Hide
          Michelle Cannon added a comment -

          Took the ice-4401 your team compiled and had some of our testers try it with ie6 and ie7. 3 developers tested this today.

          Results with both browsers were the same.

          usecase 1

          Type some value into the first text box
          type a correctly formated date into the calendar textbox ie. 04/20/2009
          Click tab

          Result : focus went correctly to the next field

          usecase 2

          type some value into the first text box
          type a partialy formatted date into the calendar textbox ie 4/30/2009 (this will trigger date converter)
          Click tab

          Result : focus goes to the first text field

          Show
          Michelle Cannon added a comment - Took the ice-4401 your team compiled and had some of our testers try it with ie6 and ie7. 3 developers tested this today. Results with both browsers were the same. usecase 1 Type some value into the first text box type a correctly formated date into the calendar textbox ie. 04/20/2009 Click tab Result : focus went correctly to the next field usecase 2 type some value into the first text box type a partialy formatted date into the calendar textbox ie 4/30/2009 (this will trigger date converter) Click tab Result : focus goes to the first text field
          Hide
          Ken Fyten added a comment -

          I can reproduce step #2 on IE7.

          usecase 2

          type some value into the first text box
          type a partialy formatted date into the calendar textbox ie 4/30/2009 (this will trigger date converter)
          Click tab

          Result : focus goes to the first text field

          Show
          Ken Fyten added a comment - I can reproduce step #2 on IE7. usecase 2 type some value into the first text box type a partialy formatted date into the calendar textbox ie 4/30/2009 (this will trigger date converter) Click tab Result : focus goes to the first text field
          Hide
          Adnan Durrani added a comment -

          ICE-4461 fixes it.

          Show
          Adnan Durrani added a comment - ICE-4461 fixes it.

            People

            • Assignee:
              Adnan Durrani
              Reporter:
              Michelle Cannon
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: