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.

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

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

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.

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.

created forum post
http://www.icefaces.org/JForum/posts/list/12637.page

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

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

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!

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.

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.

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?

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.

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

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.

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.

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.

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.

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

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

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.

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.

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

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

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

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.

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

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

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

ICE-4461 fixes it.