Needing to click on ComboBox multiple times to get focus
Needing to click on ComboBox multiple times to get focus
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.
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!
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.
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
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.
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.
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.
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.