[Isomorphic]

We would have to do the delay for buttons that have server callback actions because in real-time scenarios, buttons can perform any actions - we do not actually know which one would invoke a fetch - would you see this as a problem?

This problem of the button losing focus in response to the click handler appears to be quite specific to this case. The exact sequence of events (including the edit) appears to be required to get into this bad state, and the bug is tripped as a result of both the setDataSource() and the filterData() calls combined.
Since it's quite a specific case our assumption is that you can apply it to the specific button within your app where you've encountered the problem, rather than trying to apply it generally to every button.

If in your case the sequence of events involves an asynchronous server request (triggered from a button click) actually kicking off the setDataSource() / fetch operation that causes focus to be lost by the button, you could have the callback from that server request check whether the button has focus (looking at button.hasFocus), and if it does, use this same workaround code (button.delayCall("focus")) to ensure focus is reset to the button.

If you find this doesn't work as expected within your app, or is not practical to apply for some reason, let us know.

[acarur01]

The problem is it is not our application. It is our client's application. Any of our other clients can have the same setup more or less and we would not really know which button triggers this specific problem unless we keep track of the element on the screen which causes the server call back and check it in the list grid's dataArrived such that if it is a button, we would call focus on it again.

[acarur01]

I just tired on the 12-05 branch and the chrome issue with the date range filter editor is still not fixed.

I also noticed another issue in Chrome with that same scenario. If you click Logout then tab, it will go to the first filter editor field then quickly jump to the second one.

[acarur01]

Confirming that Issue #1 is not reproduceable in the 8.2 branch BUT the issue I mentioned in Chrome:

"I also noticed another issue in Chrome with that same scenario. If you click Logout then tab, it will go to the first filter editor field then quickly jump to the second one."

now happens in IE8 as well but with IE8, you have to tab into the logout button instead of clicking on it, then tab to the listgrid filter editor.

[Isomorphic]

Wow - this thread just keeps getting longer!
To tackle these point by point:

- The Chrome issue where focus gets "stuck" on the icon should be resolved in the latest build in both 8.1 and 8.2 branches (That'd be Dec 6, and builds going forward). The fix only went in yesterday so you wouldn't have seen the fix on a build dated Dec 5

- The new issue where a tab from the "logout" button into the top of the filter editor is jumping past the first field sounds like one we'll just have to investigate and get back to you on. Expect an answer later this week!

- It sounds like the workaround of calling button.focus on a delay in order to prevent the issue where the button loses focus is going to be difficult for you to apply given the fact that this applies to a customer's app where you don't have control over the specific button where the problem is occuring and need a more general solution or a framework fix.
While the issue does not manifest in 8.2, we've already established that upgrading to 8.2 is not an option for you (That's correct, right?)

Ok - so - here's a workaround that should be able to be applied more generally: You can query *the current focus canvas* via isc.EventHandler.getFocusCanvas(). This is an unexposed (internal) method so we can't absolutely guarantee it won't change in a future release but I'm noting that we've exposed it to you and if we do ever change it we will be sure to update this thread to let you know [also beyond 8.1 you should no longer need this workaround].
Therefore you can do

var currentFocusCanvas = isc.EventHandler.getFocusCanvas();
// ... do code that is expected to kill focus 
// - so grid.setDataSource() / grid.fetchData()
if (currentFocusCanvas != null) currentFocusCanvas.delayCall("focus");

You could presumably bundle this up into a function that will be called within your client's application regardless of how exactly they use it.
Please take a look and see if this will work for your usage.
We will also revisit the underlying code and see if we can come up with a safe way to get this change into the 8.1 branch.

[acarur01]

As is our internal ticket for focus issues! :)

Thanks for the feedback. At this point we cannot upgrade to 8.2. Once it has been released then we will look into upgrading.

We actually already use isc.EventHandler.getFocusCanvas() for certain behaviou r we need for re-applying focus and we are aware that we take a risk since it is undocumented. It would be extra helpful to get a notice if this does change :)

I will try the workaround and let you know. I'll also download 12-06 build to test the Chrome issue again.

[acarur01]

Ok. The Chrome issue is fixed so it no longer gets stuck at date range item.

I tried the workaround you suggested in the standalone and it works like a charm but as soon as I place it into our environment, it still does not function properly. I tried calling it right after the fetchData call, tried placing it in the fetchData callback as well as in dataArrived and it still does not work. I even tried delaying by 100ms and no luck. How do I approach debugging this in our env?

[acarur01]

Scenario below is now fixed in 12-08-2011 build

Scenario #2 - happens in both IE8 and Firefox6.0

1. Tab to the list grid body.

2. Tab to the Apply button and press “space” or “enter” to refresh the data in the grid list

3. Tab again. The focus is on the textfield.

4. Continue tabbing until the focus is back on the "Logout" button. You'll notice that the focus goes to the listgrid header instead of the filter field.
5. Tab again. Now the focus is on the first header.
6. Tab again and now the focus is in the filter field - tab through all the filter fields, this time it skips the header and goes directly to the listgrid body then the apply button.

Scenario below now occurs in IE8 using 12-08-2011 build

- The new issue where a tab from the "logout" button into the top of the filter editor is jumping past the first field sounds like one we'll just have to investigate and get back to you on. Expect an answer later this week!

[Isomorphic]

Just a quick update to let you know this has not fallen off our radar. We're aware of 2 outstanding bugs in this thread that still need resolution (against or via an update to 2.5 code):

1) The issue where the tab keypress from the logout button is causing focus to briefly appear in the first field, then move immediately to the second field in the filterEditor of the grid

2) The issue where clicking on the "Apply" button causes focus to mysteriously be taken from the button when the grid redraws. Given the fact that the workaround we gave you isn't solving this issue for you, we're taking another look here to see if we can come up with a framework fix or patch that will get you past this.

No solutions yet but we're reproducing the problems on our end and will let you know when we have a fix (or reliable workaround)

[acarur01]

I didn't realize 8.2 had been released already! So according to the blog, " upgrade existing licenses at 30% off until the end of the year." - does this mean that we have to get a new license agreement going before we can use it as supported customers?

[Isomorphic]

If you have an 8.x license, 8.2 is a free upgrade.

[Isomorphic]

Another update. We have just resolved the issue where in Chrome and IE, when tabbing into the filter editor from the "Logout" button, focus would momentarily appear in the first edit field, then jump to the second edit field.

However fixing the issue with the "Apply" button spontaneously losing focus is still proving elusive.
Since the workaround we provided fixes this issue for you in your test environments, though not in production mode, we could focus on getting that working there.

Or if you are considering an upgrade to 8.2 this may become moot of course.

Housecleaning note: This is an extremely long thread. If you perform an upgrade to 8.2, you will of course do some extensive testing of your own.
As we've discussed in earlier posts most of these issues should already be resolved in 8.2, but if any of them, or variations of them that we haven't previously caught, do appear to be an issue there we'd recommend starting a new thread for discussing these.
Otherwise it will become difficult to identify exactly which bugs apply where.

Also, be aware that though 8.2 has only just come out, we have already solved a bug that didn't make it into that release (this one!). As with the 8.1.x branch, we will be maintaining an 8.2.x branch - a bugfix only branch containing fixes applied since the public 8.2 release, while new feature implementation and other more experimental development will continue in nightlies under 8.x

Regards
Isomorphic Software