JDK-8159963 : [hidpi] Ubuntu 16.04: cannot select ChoiceBox item
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-06-21
  • Updated: 2016-12-16
  • Resolved: 2016-12-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Ubuntu 16.04 (Unity) + HiDPI + JDK9b122.

Please run the following sample:

import javafx.application.Application;
import javafx.scene.Parent;
import javafx.scene.Scene;
import javafx.scene.control.ChoiceBox;
import javafx.stage.Stage;

public class ChoiceBoxApp extends Application {

    public Parent createContent() {
        ChoiceBox cb = new ChoiceBox();
        cb.getItems().addAll("One", "Two", "Three");
        cb.getSelectionModel().selectFirst();
        return cb;
    }

    @Override public void start(Stage primaryStage) throws Exception {
        primaryStage.setScene(new Scene(createContent()));
        primaryStage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

the ChoiceBox is broken: can't list the items or select one of them.
Comments
core issues fixed by JDK-8163496 New issue filed as JDK-8171336
16-12-2016

JDK-8163496 solves the initial complaint I am seeing the popup window in the wrong place, but only with GDK_SCALE=2 and using gtk3 on Ubuntu 16. so will re-purpose this JBS to address that complaint. GDK_SCALE=2 javafx -Djdk.gtk.verbose=true -Djdk.gtk.version=3 ChoiceBoxApp
15-12-2016

Should be closed after JDK-8163496 is resoved.
15-12-2016

David, don't you mind if I take this bug?
02-12-2016

the same for ColorPicker, DatePicker also affects HTMLEditor as it has 2 ColorPickers embedded (for background and foreground color)
19-09-2016

the issue isn't reproducible with JDK8 on the same machine (HiDPI, Ubuntu 16.04, GTK3)
14-09-2016

This was originally posted as a comment on JDK-8159968, but most of the discussion of these issues is in this comment thread, so I am duplicating the comment here... Some information that might help vaguely recollected from when I worked on it a few weeks ago... I'm pretty sure that the last I left it (testing on 14.04, not 16.04, but using GTK3) there was a discrepancy between what the GDK events listed as the location and the location we computed by querying GDK calls. Part of the issue is that the event lists the location of the child window, but we need to know the location of the decorated frame instead, and part of it may be that GDK uses "cached information" for some of its calls in order to avoid a round trip to the X server. I thought perhaps the issue might be that we process the CONFIGURE event first before we hand it to GDK, but after I changed the order and handed the event to GDK first and then ran our own event processing code, we still seemed to come up with the wrong answer. Potential solutions might be to either force GDK to sync up (though this happens once per window move event so we'd have to make sure it wasn't that expensive an operation), or to get the location of the decorated frame some other way than to use the GDK query call we are currently using...
13-09-2016

asking for 9-client-defer-candidate as there are no resources to address this in 9.
11-09-2016

Reassigning to David for further investigation on why the position functions are misbehaving (mostly on GTK3, but sometimes on GTK2 as well).
08-09-2016

This looks like stale values managed by GDK. In both cases GTK2 and GTK3 we get a GDK_CONFIGURE event that has the correct position in it, but we then notice that the window is decorated and decide to call gtk_window_get_position() instead to get its position (which will account for the decorations), but that function returns a bogus location that is in the upper left of the screen. If you de/reactivate the window or move it, then that function will start returning reasonable values, but until you move the window, the popups will be in a bad location. The issue with gtk_window_get_position is still under investigation. It does happen on GTK2 as can be seen by a simple program that shows a window (with no controls on it) and prints its position when you click on it - it will get its location wrong about 1/10 times on GTK2, but nearly all the time on GTK3. A window with a widget that has a popup seems to get the right location from the gtk_window_get_position function 100% of the time on GTK2, but almost never on GTK3.
18-08-2016

What's odd, though, is that the first time the popup appears it is misplaced, and if you continue to use it in the misplaced position, even dismissing it and bringing it back, it continues to appear in the misplaced position. But, if you switch to another top level window and back to the app window, then the popup appears to fix itself and now appears correctly positioned over the choicebox control, so there is something going wrong only on the initial location of the popup.
11-08-2016

After the fix for JDK-8159892 the initial window renders fine, but the popup window is misplaced on the screen.
11-08-2016

Very likely this is a dup of JDK-8159968 and thus possibly also of JDK-8159892.
04-08-2016

in case of non-HiDPI display the list of items appears in a wrong place if scale > 1
22-06-2016

scale = 1.5 was used for testing. when using scale = 2, the stage is simply rendered incorrectly (JDK-8159892) - but at the same time can see some corrupted item list aside from the application
21-06-2016