May actually be a Dialogs API issue - I've seen at least one other dialog that shows up like this.

*** Bug 174153 has been marked as a duplicate of this bug. ***

Created attachment 93908 [details]
Normal sized import dialog

Tim, could you show me what is full-screen height? Do you mean this attached dialog? It works for me in NB6.9M1 build, on ubuntu. Is it only Windows problem? Thanks

Unfortunately, PrintScreen/Alt-PrintScreen is broken on my Windows box or I would have already attached a screen shot :-(

However, I just tried it on JDK 6, and it appears the problem is JDK 7 specific - I am running build 1.7.0-ea-b72

So, we should probably file a JDK bug and then close this.  I have no idea where, internally, you file a JDK bug these days, though.

Confirming. Saw it today for the first time. Just started 6.7.1 installed from the native packages (and thus using the OpenJDK6 available through the native packages) on my Ubuntu 9.10.

See the screenshot.

Note that OpenJDK6 is a variant of JDK7 sources (with 7 features removed), so Tim may be correct about this bug being JDK7 specific.

Created attachment 93955 [details]
Tall import settings dialog on OpenJDK6

As you can see, the Yes/No buttons are not reachable on Linux.
If I remember right, they were reachable on Windows at the screen bottom, when experiencing this bug on Windows 2 times, even with Sun's JDK 6, see bug 174153.

Also happens on module projects, if you press Alt-Shift-U and get the dialog asking if you want JUnit 3 or JUnit 4.

Perhaps look at the preferred size of the panel containing the buttons?  OK/Cancel dialogs seem to be fine.  Perhaps something in the implementation of DialogDisplayer specific to handling centered buttons or custom options?

I can confirm it's reproducible on OpenJDK1.6, JDK1.7b74 as well. It's easy fixable on NetBeans in Import Settings Dialog (btw. it's pure Java, no NetBeans Dialogs infra). I'm going to try make a simple SwingApp demonstrates this problem and report it back to JDK team.

Could you publish the link to the JDK bug here, when available?

Filed as jdk bug 6925473, I'll add link to this bug when it's public.

*** Bug 180635 has been marked as a duplicate of this bug. ***

Jirko, could the bug be workarounded as suggested in the evaluation of the JDK bug, specifically in this dialog that the user sees as the first NetBeans UI?

Yes, it can be. Enough to specify a proffered size to that dialog.

The workaround applied in core-main/rev/6b1d107138a1

Need a similar fix for the JUnit 3.x/4.x dialog.  Note that setting preferred size is not really a good fix, since it will make the dialog the wrong size on systems with large fonts.

A simple workaround can be implemented in DialogDisplayer:
 - Check the JDK version.  If it is one known to have the problem, 
   - call pack() *twice* before showing the dialog.  The first call will set an incorrect size;  the second one corrects it.

The root problem is in BasicTextUI.getPreferredSize(), which is using Integer.MAX_VALUE for its dimensions, and that either:

A. Something is caching this initial (pre-parenting) value, or
B. The call to getPreferredSize() comes 

Until the JTextComponent 1. has a parent, and 2. getPreferredSize() has been called at least *twice* the values returned by getPreferredSize() are nonsense.  If you run the following example, you will see the following logged:

PREF SIZE java.awt.Dimension[width=404,height=4324] displayable? true
PREF SIZE java.awt.Dimension[width=404,height=64] displayable? true

The dialog size is set from first call.  isDisplayable() is returning true, so the component *has* a parent and a peer, but the code that gets run in BasicTextUI uses Integer.MAX_VALUE to compute its size as if the text component's getSize() method returns 0,0.  The most likely source of the problem is line 910 of BasicTextUI.getPreferredSize(JComponent) (JDK 1.7.0-ea sources) - rather than compute the preferred size properly if the component has a parent, the first call to getPreferredSize() will *always* trigger use of Integer.MAX_VALUE.  The next call will return non-0 dimensions, so proper preferred size computation will run.

The NB workaround is to make sure getPreferredSize() is called twice after a peer is present, to size the dialog.

A JDK fix would be to check the displayability of the component, and compute the preferred size properly on the first call to BasicTextUI.getPreferredSize(JComponent) where the component has a peer.  The specific bug is relying on component.getSize() == 0,0 to set up nonsense size values, rather than checking isDisplayable(), and if true, not using nonsense values.

Here is a plain Swing example of how to reproduce the problem.  Just uncomment the second call to pack() to fix (*or* invoke dlg.setVisible(true) from some thread other than the AWT thread). 

public class Main implements Runnable {
    public static void main(String[] args) {
        EventQueue.invokeLater(new Main());
        //IF YOU CALL run() here instead, no bug
        //run();
    }

    public void run() {
        JTextArea area = new JTextArea("Foo foo fru foo foo fru foo foo fru " +
                "foo foo fru foo foo fru foo foo fru foo foo fru foo foo fru " +
                "foo foo fru foo foo fru foo foo fru foo foo fru foo foo fru " +
                "foo foo fru foo foo fru foo foo fru foo foo fru foo foo fru " +
                "foo foo fru foo foo fru foo foo fru foo foo fru foo foo fru " +
                "foo foo fru") {
            @Override
            public Dimension getPreferredSize() {
                Dimension result = super.getPreferredSize();
                System.err.println("PREF SIZE " + result + " displayable? " + isDisplayable());
                return result;
            }
        };

        area.setFont (UIManager.getFont("controlFont"));
        area.setColumns(50);
        area.setLineWrap(true);
        area.setWrapStyleWord(true);
        JPanel msg = new JPanel(new BorderLayout());
        msg.add (area, BorderLayout.CENTER);

        JDialog dlg = new JDialog();
        dlg.setLayout(new BorderLayout());
        dlg.add (msg, BorderLayout.CENTER);
        dlg.pack();
        //UNCOMMENT THIS LINE TO FIX THE BUG
//        dlg.pack();
        dlg.setVisible(true);
    }
}

I suspect this will turn out to be some sort of call-order bug, where getPreferredSize() is called too early if setVisible(true) is called from the event thread.

(left out the rest of a sentence)

B. The call to getPreferredSize() comes too early

BTW, an even simpler solution would be:  Don't use a JTextArea, pass a String or use a JLabel instead.  I'm guessing it is a JTextArea for some sort of accessibility reason, but if the accessible properties of the JLabel or dialog are set up correctly, that should be fine too.

Integrated into 'main-golden', will be available in build *201002140200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6b1d107138a1
User: Jiri Rechtacek <jrechtacek@netbeans.org>
Log: #179525: Import settings dialog is full-screen height; a hot workaround of jdk bug 6925473

A workaround added also in impl of DialogDisplayer - core-main/rev/bffccf28cdb2

Integrated into 'main-golden', will be available in build *201004090201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bffccf28cdb2
User: Jiri Rechtacek <jrechtacek@netbeans.org>
Log: #179525: another workaround of jdk_bug_6925473

JDk team also fixed reported bu gin JDK7(b97)