JDK-6754618 : Frame triggers componentMoved and componentResized events when restored from iconified state
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,7,8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows,windows_xp
  • CPU: x86
  • Submitted: 2008-10-01
  • Updated: 2018-07-05
  • Resolved: 2014-03-17
Related Reports
Relates :  
Relates :  
Description
Frame triggers componentMoved and componentResized events when it is restored from iconified state. This is reproducible on Windows platforms starting jdk6. This is not reproducible with jdk5.

To reproduce, run the below code. It shows a Frame in iconified state. Restore it and see for 'Resized', 'Moved' messages in command window.

import java.awt.*;
import java.awt.event.*;

public class FrameEventTest {
    public static void main(String[] args) {
        Frame f = new Frame();
        f.setExtendedState(Frame.ICONIFIED);
        f.setSize(200, 200);
        f.addComponentListener(new ComponentAdapter() {
            public void componentMoved(ComponentEvent event) {
                System.out.println("Moved");
            }
            public void componentResized(ComponentEvent event) {
                System.out.println("Resized");
            }
        });
        f.setVisible(true);
    }
}

Comments
EVALUATION Although technically this issue is probably caused by the fix for 5025858, we believe this bug isn't a regression in its nature. 5025858 resolved an issue with douplicate events on each resize, which indeed was a severe issue because it might slow down live-resizing quite significantly, and therefore that issue had to be fixed. However, this CR (6754618) is about delivering additional events upon deiconifying a window: 1. This operation doesn't happen often (as was the case with live resizing when we receive hundreds of RESIZE events), therefore this issue isn't severe at all. 2. Deiconifying a window actually does changes the size of the window, at least from user's perspective. Therefore, delivering the resize event shouldn't look strange in this case. 3. Moreover, AWT specification never calims that a particular event must (not) be delivered in certain cases. Actually, AWT simply translates the events received from the native system, and we consider this approach 'right'. Given the above points, I'm removing the keyword 'regression' from this CR.
03-08-2011

EVALUATION Thoughts to consider: http://mail.openjdk.java.net/pipermail/awt-dev/2009-April/000614.html http://mail.openjdk.java.net/pipermail/awt-dev/2009-April/000615.html In a nutshell: we need to make sure the events get generated by the native system. Perhaps, we should also reflect the fact in the specification of the affected events.
15-10-2009

EVALUATION This looks like a regression of 5025858. At least the Windows part of that fix looks suspicious, however it can't be reverted without touching the shared code as well...
06-10-2008