I'm certainly happy to have you post a test case either here or on the support ticket, but was concerned that you might not have the time to produce a complete test case where we can reproduce the issue, and wanted to remind you that we can possibly help with code you'd rather not become public. Of course, it is always our preference to have it as simple as possible for easy verification, and such code likely can be made public - but these aren't the only concerns when developing a product.

I added this code and the click event doesn't fire until it "starts working".

I have no idea, why the event isn't being fired, or what is causing that event to not go the combo box, when clicking on the cell does indeed cause the combo box to render. The blur event gets fired instead when I click on it again.

I am still trying to reproduce in test case and tried to scale back my actual code so I could provide that as well, but no luck.

Since this forum topic is considered "fixed", I will probably move this back to my internal ticket and look at creating a new forum topic when I have something that can be shared with others on this.

If you have any debugging/event monitoring to recommend, please let me know.

Provided you have the java.util.Logging support that GWT provides enabled, you can add this line to your app to get all kinds of other focus/click/keystroke details from within many of GXT widgets:

Code:

<set-property name="gxt.logging.enabled" value="true" />

I don't recall if IE8 has a console object that logs can be sent to if you compile this in, but it will also go to your Dev Mode console and the stdout log in your IDE when debugging. These details may or may not be enough to help you.

The fact that the dom event doesn't go off until it 'works' is possibly an indication that the combo isn't being attached completely. The addDomHandler method should completely circumvent the cell code, and just look for events that directly occur on the combo box itself (a div, an input and an image, you wont get the dom events from the listview).

Seems like (in my application) a combo-box will require 2 clicks (initially) to bring down the combo-box, but after that a single click will cause the drop-down to work.

On the same page as the grid, is a combo box. Once that combo box is doubled clicked, then the combo box in the row will work just fine.

My page is BorderLayoutContainer and if I start the page with my content, then it will also work. However, that isn't how the page is normally rendered. Instead there are links and actions performed first. Each link / action sets the main content of the BorderLayoutContainer to a different screen. So, when I click on an anchor that fires an event to render the this widget, I have issues.

I'm still frustrated/rambling here. I was hoping I would be able to extract a test case, but still working on that. I'm wondering if how the combo box displays a div for the drop-down could be conflicting with itself....

So, can you think of any reasons why a combobox on first attempt (NOT in a grid) would require 2 clicks on render the drop-down?

Well, I am able to replicate the issue with our application in Chrome 25, so this isn't unique to IE8.

Chrome's behavior is different, the drop-down arrow never goes away, but the pop-up never gets rendered either. I have have the combo box loose focus before clicking on it again to get the pop-up to render.

Also, I don't think the issue is with 1 row in the grid anymore, once a drop-down on a combobox works, then the one on the grid works.

It certainly sounds like an issue, but not one I am able to reproduce in IE8 or chrome with the existing inline grid editing examples or your earlier example.

As for a place to discuss, I'm happy to have conversation about a bug that can't be reproduced continue here in a FIXED ticket (we agree the reported bug is fixed, right?), but opening a new one seems premature. You could also start a post in discussion.

Yes, I agree this defect is fixed. It seems (to me) I had 2 bugs in my app causing the same behavior, and this fix addressed one of them.

I just found some things that make me thing it has something to do with calling focus() on a widget that gets removed. And I know there were a few fixed issues in 3.0.3 that dealt with focus(). Since I'm close to this, knock on wood, I will probably end conversation at this point and open a new defect if/when I'm able to reproduce it.

If it is focus() releated, that gives me hope I can also work around it.

I don't see a blur() method, however. And we do call focus when we display our new component, so just setting focus on another, I do not think, is causing the issue. But the fact that a widget had focus and then that widget was removed from the DOM.

Component defines focus(), but not blur() - this covers the case of programmatically saying 'here, look at this next thing', but leaves open the question of how the app looks at nothing. Element/XElement has focus()/blur(), though not all elements are made to accept focus (needs a tabindex to make sense), and it may not trigger the right sorts of interaction (focus on a ComboBox is tricky because of the dropdown, a totally distinct ListView object).

We may need to consider it though, if that is the root of your issue. That said, if focus has to be removed from an item before it can be detached from a parent, that is going to be somewhat annoying to implement:

IE complains loudly when you focus or blur on things which aren't visible, whereas most other browsers just ignore it as nonsense. All kinds of try/catch blocks exist in GWT/GXT to manage this 'exceptional' case.