PDA

View Full Version : Setting focus on individauls buttons within a GXT buttonbar



sri2k1us
21 Jul 2010, 1:25 PM
I Have a Dialog with couple of text fields and OK,CANCEL button on a buttonbar. When I use my tab key in keyboard to navigate the dialog , I could not reach the OK or CANCEL button instead the focus is always set to the button bar. Is there a way to set focus on the individual buttons so that I can use my keyboard instead mouse to navigate over the dialog ?

sven
21 Jul 2010, 1:28 PM
Which GXT version are you using?

sri2k1us
21 Jul 2010, 1:31 PM
@sven - I am using GXT 2.1.0.

sri2k1us
19 Aug 2010, 9:51 AM
@sven - any updates / help on this issue ?

sven
19 Aug 2010, 2:12 PM
I tried this on a dialog with GXT 2.1.1 and it works without any problems: http://www.sencha.com/examples/explorer.html#dialog

Can you try this against a later version?

sri2k1us
24 Aug 2010, 2:20 PM
I tried my code with GXT 2.1.1 and did not notice any change in the behavior. My dialog has text fields(see the attached picture in my first thread) and I want the Url field to have the initial focus and focus should shift on subsequent tabs to the ok button. The example you pointed out has the focus on the Ok button initially but when you starting hitting tab key, the focus shifts out of it and never comes back to Ok button again.

sven
25 Aug 2010, 2:01 AM
the focus shifts out of it and never comes back to Ok button again.

Its getting back to the ok button again for me. Just hit tab often enough.

lenards
25 Aug 2010, 6:54 AM
(I work w/ sri2k1us and have looked into the issues we are experiencing with tabbing)

@sven - what browser are you using? We are seeing this awkward tabbing behavior in Firefox 3.6 and GXT 2.1.1.

It's not a lack of tabbing on our part. It seems that we cannot get our tab behavior to be reproduced in your environment. We can record a screencast of the behavior so you can see it firsthand along with producing the OS, Browser, GWT, and GXT versions if that would be helpful.

Plus - would you like to tell users "oh, just hit tab often enough"? Such responses do not go over well.

sven
25 Aug 2010, 7:02 AM
Hitting tab just gets you to the next element in tab order. If you hit tab often enough, you will get back to the dialog. I am using Firefox 3.6 too and for me, it returns back to the ok button after hitting tab often enough (going over all other focusable stuff). First it goes to the addressbar and someother native controls and than back to the webapplication. We are not doing anything special with the tabing behaviour

What was wrong with that response? Its actually what you have to do to get back to the element. I have to hit tab 26 times in that example to get back.

Do you have any special plugins installed to firefox that can change the behaviour?

sven
25 Aug 2010, 7:05 AM
You can also try this against 2.2 RC1 as there were a couple of focuschanges: http://www.sencha.com/examples-dev/explorer.html#dialog
But there again,, after hitting tab often enough, it returns back to the dialog for me


It seems that we cannot get our tab behavior to be reproduced in your environment
So it is working for you in my linked example and not in your application? Can you please post some testcase of what your code looks like and that is runnable for me.
In the other response i understood it that it is also not working in the linked example from me.

lenards
25 Aug 2010, 7:20 AM
What was wrong with that response? Its actually what you have to do to get back to the element. I have to hit tab 26 times in that example to get back.

In Firefox 3.6.8, for my co-worker (who performs QA testing) - the link example dialog will not tab back to the "Yes" button even after hitting tab 30+ times. It seems cycle through the native browser controls (the browser tab, address-bar, search-bar) and only hits the theme dropdown (which has the text "Blue Theme") and the left-pane "Navigation" dialog.


Do you have any special plugins installed to firefox that can change the behaviour?

The plugins he has installed are: Firebug, XPather, XPath Checker, Elasticfox, and Selenium IDE.

sven
25 Aug 2010, 7:23 AM
I tried this on three different computers with firefox and all work as expected. Is there anything special i need to do? Also is this the exact same problem you have in your application? If not, you will need to provide a testcase for this.

Can you try it against 2.2 RC1 too (http://www.sencha.com/examples-dev/explorer.html#dialog)?


Is it possible i can get remote desktop access to this computer? Please email sven@sencha.com for this

lenards
25 Aug 2010, 7:31 AM
So it is working for you in my linked example and not in your application? Can you please post some testcase of what your code looks like and that is runnable for me.

The GXT Example that you have linked is not working in the local environment for sri2k1us and our QA testing (all development is on Mac OS X). I do not have specific browser version and plugins for sri2k1us, but I know he was testing with Firefox. Our QA Testing was able to reproduce the behavior from Firefox in Safari 5.0.1.

Our issue with our application is that focus is moving from the control before the "OK" button in a dialog directly to the address bar. This is frustrating behavior for user's trying to use tab navigation to fill in information and complete the dialog.

sri2k1us is working on providing a test-case, source code, and a public facing deployment so that it can be tested there in addition to locally.


In the other response I understood it that it is also not working in the linked example from me.

The frustrating part is that the linked example is working for me in my local environment. Accept that for GXT 2.1, it is taking 24 tabs to return to "Yes" button. In the GXT 2.2 RC1, it is taking 23 tags to return to "Yes" button (but the dialog starts on "No" - so I believe that accounts for the "off-by-one").

sven
25 Aug 2010, 7:33 AM
The frustrating part is that the linked example is working for me in my local environment for GXT Example linked
Yes it is also working for me on all computers i have here to test it.


Accept that for GXT 2.1, it is taking 24 tabs to return to "Yes" button. In the GXT 2.2 RC1, it is taking 23 tags to return to "Yes" button (but the dialog starts on "No" - so I believe that accounts for the "off-by-one").
In GXT 2.2 there were a couple of focus changes and the default button changed.

lenards
25 Aug 2010, 7:42 AM
I tried this on three different computers with firefox and all work as expected. Is there anything special i need to do? Also is this the exact same problem you have in your application? If not, you will need to provide a testcase for this.

The crux of our application's issue is that we're getting *jumping* to the native browser widgets before we would expect. So you have something like this "text" dialog:

*Job: _________________ (TextField)
Description: ___________ (TextArea)

| Ok | | Cancel | (Buttons)

The focus (shown by *) is at the Job TextField. You tab from Job TextField to the Description TextArea. When you hit tab next, you expect it would go to the Ok button. But instead, it jumps straight to the address bar of the browser.

Originally, we were experiencing the above dialog interaction that you would tab from Job TextField to the Description TextArea. Then tab from Description TextArea to the ButtonBar conaining the buttons. When you hit tab next, you expect it would go to the Ok button. But instead, it jumps straight to the address bar of the browser.

I hope that makes our issue more clear. It really is odd (in my local environment, it behaves as expects)

The severity of the issue is that our users would expect to be able to tab from the focus widget of the dialog from widget to widget to reach "Ok" - but they cannot.

The tangent about tabs returning to the original focus widget has to do with a design to restrict tabbing to the GXT/GWT widgets within our application. But that really is not the crux of the issue.


Can you try it against 2.2 RC1 too (http://www.sencha.com/examples-dev/explorer.html#dialog)?

I will have our QA lead test this and see if it works.


Is it possible i can get remote desktop access to this computer? Please email sven@sencha.com for this

Remote Desktop Access may not be possible, I can explored that option and get back to you. But I can record the on-screen interaction.

lenards
25 Aug 2010, 8:08 AM
@sven - I replied with a description of the actual problem we are experiencing in our application and it appears that I have been moderated. I believe it was the number of posts I made in a short timeframe. But I would like to avoid having to retype my explanation. It was a reply to your post, #12 in this thread.

Thanks.

sven
25 Aug 2010, 8:10 AM
I approved that reply.

I remote desktop access would really be the best to actually test it for myself why it fails and what it is doing.

lenards
25 Aug 2010, 8:25 AM
I approved that reply.

Thank you.


I remote desktop access would really be the best to actually test it for myself why it fails and what it is doing.

Understood. I just do not know if it is possible with our network setup. I will look into it though.

sven
25 Aug 2010, 8:45 AM
Also can you please open a ticket inside the ticketsystem for this.

hhiplaz
6 Sep 2011, 10:00 AM
In the GXT mail demo (http://www.sencha.com/examples/mail.html), if I use Firefox I can tab to the buttons on the login dialog. In Safari, the tab key never focuses the buttons.

lenards
6 Sep 2011, 10:05 AM
Thanks hhiplaz - I'll try that out.

sven
6 Sep 2011, 10:11 AM
In the GXT mail demo (http://www.sencha.com/examples/mail.html), if I use Firefox I can tab to the buttons on the login dialog. In Safari, the tab key never focuses the buttons.

I just tested this against Safari 5.1 running on Windows 7 and it works for me.

hhiplaz
6 Sep 2011, 10:27 AM
I can confirm it works in Safari 5.1 on Windows 7, but not Safari 5.0.4 on Mac OS 10.6.

lenards
6 Sep 2011, 11:25 AM
It works for me in Chrome 13.0.782.218 on Mac OS X 10.5.8.

I also confirmed that mail-demo working in Safari 5.0.6 [1] on Mac OS X 10.5.8. It does have a few tabs where it is not clear which UI-element is selected.

[1] Safari version 5.0.6 (5533.22.3)