###@###.### 2002-04-29

J2SE Version (please include all output from java -version flag):
  java version "1.4.1-beta"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b08)
  Java HotSpot(TM) Client VM (build 1.4.1-beta-b08, mixed mode)

Does this problem occur on J2SE 1.3 or 1.4? Yes / No (pick one)
  Yes

Operating System Configuration Information (be specific):
  Windows NT & XP

Bug Description:
  The following problems might be all related to bug 4506456/4662254/4673105.
  Due that the GlassPaneDispatcher discards mouse events causing the
  applications become in a unstable state.

  Suggested fix in bug4506456 retained, (as an owner), the component just
  being clicked. If a drag operation came after that, all events
  were targeted to the clicked component (and it must be done that way).
  A large part of the dispatcher had been re-written but the new code has
  considered that the owner should be captured thanks to the first drag
  operation. In other words, the first drag event is taken into account in
  order to determinate (thanks to coordinates) the component that will own
  the drag and drop operations, i.e. the target component.
  It is not correct. The target must compulsory be the component previously
  clicked.
 
Problem1: the mouse drag event is not sent to the right owner
--------------------------------------------------------------
  In a more complex application, a click for a drag operation may run a lot
  of code or cause swap, and many operating systems merge the mouse events
  to avoid a big number of messages. Consequently between the click and the
  first drag message that will be dispatched, the mouse might have been moved
  by user, and the coordinates for the first drag do not target anymore the
  component owning the drag operation. The component that owns the drag
  operation is the component under which you have clicked.

  If try click on a button and drag very quickly and trace the messages
  below showing that the mouse drag event is not sent to the right owner.
  MouseEvent.MOUSE_PRESSED javax.swing.JButton [,174,1,39x37,.................
  MouseEvent.MOUSE_DRAGGED javax.swing.JLayeredPane
  [null.layeredPane,0,0,836x77......

  If click on a button and wait a little while before dragging, the
  mouse drag event is correctly sent to the button.
  MouseEvent.MOUSE_PRESSED javax.swing.JButton [,174,1,39x37,..........
  MouseEvent.MOUSE_DRAGGED javax.swing.JButton [,174,1,39x37,...........

  Succeeded in simulating a CPU load by generating a 500 milli-second sleep.
  It may appear too much, but it been done to reproduce the bug more
  efficiently.

  To reproduce the problem, do as follows:(InternalFrame2Hopper.java)
  - java InternalFrame2Hopper
  - Be sure the frame F2 is not active
  - In the Frame F2, click and drag the square and go out the square
    quickly. Nothing happens, drag operations are not redispatched
  - If you do the same thing again, and if the frame was previously
    active, the drag operations are reported.
  - If you do a third test while the frame F2 is disactivated, if you
    click and drag within the square while staying in the square, the
    drag operations are reported.


Problem2: mouse drags are garbagged if the frame is not selected(acitve)
--------------------------------------------------------------------
  It's quite wrong. During a drag operation, the mouse may go over another
  frame. This frame may be shown on the top of the desktop and activated
  in order to allow the user to drop a component onto this frame. In this
  case, the frame that initialized the drag operation will be disactivated
  since only one frame can be activated at a time. Therefore garbagging
  drag events when the frame is not active is wrong.

  To reproduce the problem, do as follows:(InternalFrame2Hopper.java)
  - java InternalFrame2Hopper.java
  - Be sure the frame F1 is not active
  - In the Frame F1, click and drag the square
  - Coordinates are displayed inside the square
  - You may drag outside the internal frame, outside the frame, but the
    drag is discarded definitely if you drag above the frame F2
  - If you do this operation again while the frame F1 is active, the drag
   operations are correct anywhere, even above the frame F2.


Problem3: mouse move event is not re-dispatched to the new component
----------------------------------------------------------------------
  The code that manages mouse move events generates entry and exit events
  when there is a change of components. This is correct but if the original
  event was a mouse move, and that mouse move is not re-dispatched to the
  new component, though it should be.

  As mentioned above, mouse events may be merged and not re-dispatching
  the original message is an error.

  To reproduce the problem, do as follows:(InternalFrame3Hopper.java)
  - java InternalFrame3Hopper
  - Be sure the frame F1 is not active
  - In the Frame F1, set the mouse -without clicking- near the square and
    go quickly into the square while not moving the mouse anymore. You may
    note that the last message received is a mouse enter, it should be a
    mouse move.
  - If you do the same thing again, and if the frame was previously active,
    you'll get a mouse enter followed with a mouse move, what is expected.