Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2705 in a recent build.
  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 Needing to click on ComboBox multiple times to get focus

    Needing to click on ComboBox multiple times to get focus


    GXT 3.0.3
    Internet Explorer 8
    Windows 7, 64 bit
    Developer Mode and Production Mode of GWT
    We did not have this issue with GXT 3.0.2

    I have a scenario where it requires multiple clicks to get a drop-down to appear in a combo box. It is a rather specific scenario and matches one of our application scenarios. I am hoping a fix/workaround to this scenario would address all of our application scenarios. In our application if we enter text in a text field (in a grid) it will not take on the first edit (gets blanked out).

    In this example type ahead in the combo box a color (I just have a few, so type in "black") and then select the enter key. If the type ahead shows black you would need to type the enter key twice (once for the combo box select and one for the enter event to trigger the action that will render "Panel B".

    Now if you are in panel B you can try a few things. Once things work, however, you will have to reload app and try the other scenario.

    Test 1: Try to hit the drop-down of the combo box. It will take 2 clicks to bring up the drop-down. On Panel A, the combo box only needs 1 click to make the drop down visible.

    Test 2: Try to edit the color column in the grid (one click to render the combo box and the second click to bring down the drop-down). It will take multiple clicks to bring up the drop-down and instead of just not working it will also disappear as you click.

    Also, the drop-down will flash to the 0,0 coordinate (sometimes) as you are clicking on the arrow to try to make it render.

    ScreenA.jpgScreenB.jpg

    I tested this against Chrome 25 and it seems to behave fine from there. However, our application had issues when I tested it against Chrome 25. So this concerns me.

    ComboBoxNeedingMultiClicks.zip

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    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


    Thanks for the report! I have opened a bug in our bug tracker.

  3. #3
    Sencha - GXT Dev Team darrellmeyer's Avatar
    Join Date
    May 2007
    Location
    Washington, DC
    Posts
    2,242
    Vote Rating
    2
    darrellmeyer is on a distinguished road

      0  

    Default


    The handler code that executes on key down needs to run deferred to allow the combo to properly end the current edit. Try this code:

    Code:
        panelA.addDomHandler(new KeyDownHandler() {
          public void onKeyDown(KeyDownEvent event) {
            if (event.getNativeKeyCode() == KeyCodes.KEY_ENTER) {
              Scheduler.get().scheduleDeferred(new ScheduledCommand() {
                @Override
                public void execute() {
                  content.clear();
                  label.setText(comboBoxA.getCurrentValue());
                  content.add(panelB);
                }
              });
    
    
            }
          }
        }, KeyDownEvent.getType());
    Please let me know if this works for you.

  4. #4
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    Darrell,

    Thanks for work around. So far, it looks good. However, I will continue to do more testing on this today, since the issue has been rather spuratic. I have done a variety of other things to think I fixed it, only to have it come back. What I have done prior to being able to reproduce it in my test code was to disable calling widget.focus() on various components to set initial focus.

    I'm assuming, since there is a bug number, that your work around is temporary until the fix is implemented (and then the deferred will no longer be needed).

    I will continue to test today, and respond if I see any issues. I will post again early next week, if I it is resolved. But as it looks so far, things are looking great!

    Thanks for the quick response and workaround.

  5. #5
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    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


    Unless I misunderstand Darrell, this isn't a workaround, but his analysis of the bug as 'not a bug'. Browser events are a bit annoying like this - you need to make sure the one finishes before the next begins.

    I created a bug ID assuming that there was a real issue in here - and there may yet be - but his analysis makes sense to me. You must wait until blur has run (which will be after the key event you are after here) before some work can be done.

    The best we could do as a 'fix' if I'm correct so far is to delay all key events so far that you can't even cancel them (thus breaking things like NumberField) so that you can always be in the blurred, or not, as you expect.

  6. #6
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    So should this deferred be done for click events we have also being handled this way?

    I have no problem with always having to do the "work around", just want to understand it so we can make sure I write these all correctly and what to look for if we run into similar issues like this again

    Just with how long it took to replicate this I just want to understand it fully

    Thanks

  7. #7
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    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


    When you handle DOM events, you really are on your own - there is an expectation that you will be able to deal with the timing correctly.

    TextButton emits a logical SelectEvent - in this case, we've purpose built it to handle this, and as part of that, it recieves focus so that the click comes after any other blur that will happen. If that doesn't work right, its a bug in our code, not yours.

    But any time you do addDomHandler, you are talking to the browser directly (via GWT's js->java wiring, mind) and getting the physical thing-the-user-poked (mouse, keyboard), not getting the logical intent from the widget, which has thought about it before sending to you.

    In the case of a click in a random place on the page, you get mousedown, mouseup, click, then blur (this last from the old focused widget) I believe. If you click on something that accepts the focus, then before the click goes off, you get blur (old), focus (new), click. I believe the blur/focus change happens just after mousedown, but I could be mistaken. DOM events are a world of their own, and entirely dictated by the browser.

  8. #8
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    Thanks again, and that is good information to know.

    That being said, we didn't have this issue in 3.0.2, it started in 3.0.3. Doesn't mean my code was right, but I guess I didn't feel like I was handling things "incorrectly", since it worked with the previous version of GXT.

    At least now I know of a place to look. I may also try to rewrite this w/out needing to use the dom handler for getting the enter-key behavior we are looking for.

    Thanks again.

  9. #9
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    One other thing, I can still get issues in my application, if I set focus as follows:

    textFieldLabel.focus();

    However, if I set focus this way:

    Scheduler.get().scheduleDeferred(new ScheduledCommand() {
    @Override
    public void execute() {
    textFieldLabel.focus();
    }
    });

    It seems to resolve the issue.

    Now the focus() is something I have not been able to reproduce in the a test case. And it turns out, with the Dom handler, I have more than one thing getting in the way.

    So, back to my initial statement that we only see this in 3.0.3 makes me think something is more brittle with 3.0.3 causing this to happen more easily. Not saying that is right or wrong, but just something I want to point out.

    Thanks again!

  10. #10
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    My application now behaves better with the Scheduled deferred around the addDom's contents.

    However, we do async calls between some combo boxes and I'm still getting the "double click" issue, but now in a different spot (now that I can get farther w/out seeing the double click issue).

    I will be looking into trying to create a test case for this.

    I would like to know if there is a bug (as the top indicates) or there is not a bug (as Collin has stated). I will continue to add any test cases or notes to this thread, however, as I'm able to uncover / reproduce them.

    Thanks.

Thread Participants: 2