Hybrid View

    Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2650 in 3.0.7.
  1. #1
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default Cannot select button by keyboard (after tabbing to it)

    Cannot select button by keyboard (after tabbing to it)


    GXT 3.0.3-SNAPSHOT 11/21/2012
    Windows 7 - 64 bit
    Internet Explorer 8

    I create a simple example with 2 radio buttons and a text button. I give tab index of 1 to 'yes', 2 to 'no', and 3 to 'Button'. I can tab to yes and no and cause a selection event by hitting the spacebar.

    I tab to the "Button" and it will show that I have tabbed to it (see screenshot), but I cannot hit space bar, enter, or any other key I have tried) to force the selection event to occur.



    TextButtonAndTabIndex.png

    ButtonAndTabIndexCannotSelect.zip

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    The issue here is that setting the tabIndex of the TextButton doesn't set on the correct part of the dom - buttons are very complex to draw consistently with all decoration, icons, text, menus in a cross browser way.

    At present, the tabIndex property is owned by the frame, which helps to draw these details. This is set up from within the ButtonCellDefaultAppearance class, when it invokes the follow line:
    Code:
        frame.render(sb, new Frame.FrameOptions(0, CommonStyles.get().noFocusOutline(), stylesBuilder.toSafeStyles()),
            inside.toSafeHtml());
    As currently implemented, this cannot be changed without a breaking change to the API. Two workarounds that I can initially suggest:
    * Make a new appearance subclass, copying the existing appearance, but with a getter/setter for the tabIndex value, passing that in to the frame options constructor instead of zero. This is probably the 'most correct' solution, and will be the easiest to maintain - when that api changes in a minor release, you will get an error from java instead of it just no longer working
    * Assign a real tab index in another element, such as the root of the button itself. This is more brittle, but easier to implement:
    Code:
    button.getElement().getFirstChildElement().getFirstChildElement().setTabIndex(3);
    This workaround is from looking at the structure of the dom tree from a running app, and observing that the tabIndex is present on the first child (table) of the first child (div) of the root (div) of a button. This is confirmed from observing that the TextButton (actually, all CellComponents) has a <div> at its base, then the appearance kicks in. ButtonCellDefaultAppearance.render then adds an additional wrapper <div>, and the frame.render builds a table (see TableFrame's template and html file at com/sencha/gxt/theme/base/client/frame/TableFrame.html - this is the default, as can be seen in the ButtonCellDefaultAppearance constructor).

    Thanks for reporting this, we'll provide further updates when we have a fix or a better workaround available.

  3. #3
    Sencha User
    Join Date
    Aug 2013
    Posts
    2
    Vote Rating
    0
    strmer15 is on a distinguished road

      0  

    Default


    Here's a different workaround I found, based on the existing code in ValueBaseField (GXT 3.0.6):

    Code:
    private static class MyButton extends TextButton {
    
    
            private int tabIndex = 0;
    
    
            public MyButton(String text) {
                super(text);
            }
    
    
            @Override
            public void setTabIndex(int tabIndex) {
                this.tabIndex = tabIndex;
                getFocusEl().setTabIndex(tabIndex);
            }
    
    
            @Override
            protected void onRedraw() {
                super.onRedraw();
                getFocusEl().setTabIndex(tabIndex);
            }
        }
    Internally, it does something like the second solution Colin proposed, inside ButtonCellDefaultAppearance:


    Code:
      @Override
      public XElement getFocusElement(XElement parent) {
        return parent.getFirstChildElement().getFirstChildElement().cast();
      }
    So, it seems like a less brittle solution to me, since it relies on the appearance saying what the 'focus element' is defined as, while not requiring that I create my own custom appearance or custom table frame to implement the correct rendering.

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Nice work strmer15, that does indeed appear to be a cleaner solution than what I came up with.

  5. #5
    Sencha - GXT Dev Team
    Join Date
    Jan 2012
    Location
    Arlington, WA
    Posts
    484
    Vote Rating
    15
    branflake2267 will become famous soon enough

      0  

    Default


    This issues has been fixed and merged into the 3.0.7 branch.

    Brandon