Bring up the "Prompt" window, enter some text and tab 11 times (give or take) and then hit the space bar, you will get another modal dialog to appear. Tab indexing of buttons (or any other input) on the main browser window shouldn't be available when a modal dialog is displayed.
Quick summary: Yes, it is easy to do (see http://docs.sencha.com/extjs/4.1.3/#...tact-form.html) if you don't need to support IE6-8 (and perhaps later). We've elected to not follow that approach since it would exclude those browsers. (It also doesn't work perfectly in the iframe - click on the header bar next to open in new window and hit tab a few times, and you'll have the button behind the popup selected.)
Normally the solution might be to use an event preview, but focus/blur don't get routed through that. We played with a hack where eventpreview could be wired up for focus/blur, but it ended up being just that, a hack, so it was dropped. This is the really hard part about this - we need to detect *any* focus that happens outside of the popup, and since focus doesn't bubble, you need to get it at the source. The solution above in Ext JS hooks into a specific new browser feature meant to provide this - outside of that we're looking at hacks that may miss certain cases.
I'll spend a little time re-visiting solutions out there to see if any can be implemented without either a complete registry of all widgets (and gwt widgets won't know to register themselves) or excluding certain browsers. I'll also see if I can suggest a specific workaround that will give you this effect in a consistent cross browser way, with some involvement from your own window.
Thanks for the feedback and the other forum topics on this.
It shouldn't surprise me it is an IE issue. I guess when it didn't work for Chrome, I didn't conclude that it still could be an IE issue (but you need to be consistent)... In any case, while a work-around would be great; this is something we can live with. However, it can lead to user confusion or changing something that isn't suppose to change; so I guess some information would be helpful (for a work around).
The non-IE solution requires getting an event from the dom which GWT itself doesn't support, because IE doesn't support it.
One proposed workaround (haven't yet built it) would be to draw two fields offscreen(attach them to the rootpanel, but offset them outside of view, something like -1000,-1000). Set the tabindex of those fields to different values, one high and one low, then set the tab index of each field/button in the window to between those values (possibly all the same value). Stick a focus handler on the two dummy fields - the lower one should call focus on the last focusable item in the window, and the higher value one should focus the first item. Ideally, all items in the window would have the same z-index, and so can be all assigned some higher value together. If you can make assumptions like that (z-indicies are either the default value or will be fixed after the window is shown until it is hidden), you could build a window subclass or a component plugin that re-numbers the tab indicies in this way.
This solution won't work in GXT itself, as it greatly limits what can be done with tab indicies, and changes any value that was deliberately set. The GXT 2 solution was to limit users to GXT widgets, a limitation we elected not to enforce in GXT 3 to be more flexible.
I just read the GWT PopupPanel implementation and apparently they are using a preview handler to capture focus events. I thought that this was not possible, but will test it again, and test their implementation, as I do not believe that it works correctly. There is also the added wrinkle that if it does work, it may prevent ComboBox, DateField, etc from behaving correctly (as they use their own popups on top of the current window).