JavaFX combobox hides as soon as mouse moves

@jayfella question for you (or anyone else who knows).

When I create a combo box, it displays just fine, the drop down shows, but as soon as I move my mouse to select an option it hides the drop down. Any ideas? Is this an issue between the jme input and the jfx input?

I have replicated on 2 different combo boxes.


It’s best to just use lists. Combo boxes have several related issues such as not appearing on full screen and even rendering outside the window bounds.

They act like a kind of pop out layer that JME has no knowledge of.

Saying that I guess one could be made using the regular z-based hierarchy. I’m playing around with a project that uses jfx. If I need one I’ll publish it in a separate repo for jfx controls. A default alert dialog would be useful, too. I also have things like memory and fps graphs lying around that might be useful to people.

1 Like

Those would be helpful.
My current project has some very complex UIs for the gamemasters, and make heavy use of ComboBoxes. I will add to my todo list to look at why the mouse moving causes them to hide. I have not had any issues with the drop down not showing, but then again, I have do not run my applications in full screen.

Unfortunately I have not gotten very far on my todo list these two weeks home, and I go back to work on the 3rd. So some things will have to wait until I get home again. :sob:


I have here a similar problem with a ColorPicker
(Which is basically the same like a ComboBox)
Whenever the drop down appears below
of the picker, I have no chance to select something
because it will disapear on mouse movement.
But when I align the window in a way, that the
selection area will be on top of the picker like here:

I am able to select a element without problems.
Seems to be odd.

1 Like

I just was testing the color picker and had the same issue. I did not attempt to align it though! Perhaps it is an alignment issue?

Interestingly context menus work. But also interesting when I do not base the context menu off of cursor position, and force it to be centered in the application, it is way off

x = -1;
y = -1;
if (x == -1 || y == -1) {
    x = rootNode.getScene().getWindow().getX() + rootNode.getScene().getHeight() / 2;
    y = rootNode.getScene().getWindow().getY() + rootNode.getScene().getWidth() / 2;
}, x, y);

Also interesting, when using alt-tab to select another window, the combobox or colorchooser will stay open and let you move the mouse to select something.

This circles around the same issue. They are drawn in a layer that JME doesn’t know about - which is why they are even drawn outside of JME itself. You will also notice that if you record your game they won’t appear.

I’m not sure as to why - or what layer they are drawn on. If someone - or I - can figure that out we can solve the whole issue - else a custom control or alternative will need to be made.

They are displayed as a PopupControl implemented as a object inside of:
Which is an instance of a PopupWindow, which utilizes

Scene scene = SceneHelper.createPopupScene(popupRoot);

to create a new scene in its own window… this might get complicated

An actual window with no frame? Really?


A PopupWindow is a secondary window which has no window decorations or title bar. It doesn’t show up in the OS as a top-level window. It is typically used for tool tip like notification, drop down boxes, menus, and so forth.

That is what it looks like, I am trying to find the underlying implementation right now. But that would make sense as to why it stays ontop of other windows even when the parent window is behind it:

EDIT: The SceneHelper being referenced is just a wrapper around the SceneAccessor interface, which is private to SceneHelper. Somehow the logic gets filled in, but I am not sure where… Perhaps in a platform specific jar.

EDIT 2: It is inside the javafx-graphics module, which has variants for Windows, Linux, OSX.
I am not sure what is going on in the source for each variant, I cannot find the specific implementations in the reop. The file in question is here:

@jayfella any ideas on if we can force these inside jme?

*looking into it now.

I’m not entirely sure it’s possible. At least at this stage I can’t find anything that would help. It creates a new window - which isn’t cool as far as JME is concerned. Let me think about it. I’m going to need some of this functionality, so at some point I’m going to be confronted by it.

1 Like

OK, so here is an idea.
We can get the contents of the popup by using:

ComboBox box;

//... in some method
ComboBoxListViewSkin skin = box.getSkin();
Node display = skin.getPopupContent();

The display node is the contents of the popup.
This gives us access to the popup’s scene, and idk if it would be possible, but we could just change its parent, but that might break the listeners on it.
But more possibly, we could get the scene and render it inside of jme instead of the new window?