JDK-6455716 : XAWT: should ignore smudge factor while mouse is hovering or dragging
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-08-01
  • Updated: 2015-02-23
  • Resolved: 2008-01-23
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 7
7Resolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
JDK		    : Fails:  Mustang b85 and later
Platform[s]         : Fails On: Windows XP Prof.
Failing Test [s]    : CTE_REGTEST/Generic/4731797/MouseClickZone.java

    Test source location:
    =====================
/net/jdk/export/jpse04/Regression/1.6.0/test/CTE_REGTEST/Generic/4731797/MouseClickZone.java

    jtr file location:
    ==================
/net/cady/export6/results/mustang/b93/reg/regression-cte-reg-XPpro-2006-07-28-17-11-08-0633/workDir/MouseClickZone.jtr

    How to reproduce:
    ====================
    - Set JAVA_HOME to Mustang b85 windows-i586
    - cd /net/jdk/export/jpse04/Regression/1.6.0/test/CTE_REGTEST/Generic/4731797
    - /net/koori.sfbay/onestop/jct-tools/2.1.6/archive/fcs/binaries/win32/bin/jtreg -r:/tmp -w:/tmp ./MouseClickZone.java

    Test output:
    ============
----------System.out:(11/1363)----------
Trace:
Start to wait frame "Frame with title "Mouse Click Zone"" opened
Trace:
Frame "Frame with title "Mouse Click Zone"" has been opened in 0 milliseconds
    MouseClickZone[frame0,394,222,236x324,layout=java.awt.BorderLayout,title=Mouse Click Zone,normal,defaultCloseOperation=EXIT_ON_CLOSE,rootPane=javax.swing.JRootPane[,3,29,230x292,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Trace:
Start to wait action "Wait Any javax.swing.JTextField loaded"
Trace:
"Wait Any javax.swing.JTextField loaded" action has been produced in 0 milliseconds with result 
    : javax.swing.JTextField[,74,64,37x20,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@d2906a,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],disabledTextColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],editable=false,margin=javax.swing.plaf.InsetsUIResource[top=0,left=0,bottom=0,right=0],selectedTextColor=sun.swing.PrintColorUIResource[r=51,g=51,b=51],selectionColor=javax.swing.plaf.ColorUIResource[r=184,g=207,b=229],columns=3,columnWidth=11,command=,horizontalAlignment=TRAILING]
Test Failed
----------System.err:(13/685)----------
java.lang.RuntimeException: Failed
        at Test4731797.main(Test4731797.java:70)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:82)
        at java.lang.Thread.run(Thread.java:619)

Comments
EVALUATION Confirm the problem is not reproducible anymore with JDK7.0b19. I made a test which dumps all movement events and it's OK on linux. import java.awt.Frame; import java.awt.event.MouseEvent; import java.awt.event.MouseMotionAdapter; public class Main { public static void main(String[] args) { Frame f = new Frame("Scrolling test"); f.addMouseMotionListener(new MouseMotionAdapter() { public void mouseMoved(MouseEvent e) { System.out.println("MOVED " + e); } public void mouseDragged(MouseEvent e) { System.out.println("DRAGGED " + e); } }); f.setSize(400, 300); f.setVisible(true); } } Here is the piece of its output. MOVED java.awt.event.MouseEvent[MOUSE_MOVED,(272,277),absolute(272,277),button=0,clickCount=0] on frame0 MOVED java.awt.event.MouseEvent[MOUSE_MOVED,(272,276),absolute(272,276),button=0,clickCount=0] on frame0 DRAGGED java.awt.event.MouseEvent[MOUSE_DRAGGED,(273,276),absolute(273,276),button=0,modifiers=Button1,extModifiers=Button1,clickCount=0] on frame0
23-01-2008

EVALUATION On windows we start generating DRAG event after the first mouse movemement (of course if the button is in pressed state) with no regard to smudge area. Linux still has the same scheme as before: we start sending DRAG event when the mouse has left the smugde area. Although XAWT implementation is different from Windows one but the main priority is to hold compatibility between XAWT and MToolkit. So far, it looks like a toolkit incompatibility (XAWT&Windows) but we still keep the same behavior for XAWT and Motif. As for me, I prefer the way that already implemeted on Windows. Moreover, Linux scheme could be a problem for drawing applications that rely on mouse movements even by single pixel. We should hold attention on this issue and change the XAWT behaviour when possible in JDK7.0.
17-11-2006

EVALUATION On windows we now don't send ClickEvent if the mouse moved even on 1 pixel by any axis. So far user may expect Click if he don't move mouse at all. On Linux we still send ClickEvent in regard to smudge area. I.e. in that small rectangle we do; outside - don't.
17-11-2006

EVALUATION This test started to fail after the fix for 6404008. 6404008 was considered as a regression and the fix for has reverted back the old behaviour described in 4731797. Thus, this new bug 6455716 is not a regression but an intended change. After the fix for 6404008 mouse smudge area is restored to 1x1 pixel, and all the MOUSE_DRAGGED events are reported even if mouse is moved 1 pixel any direction. At the same time MOUSE_CLICKED events are not sent if mouse is moved, and that's why the test MouseClickZone fails. As I'm not sure what behaviour is right, I'm dispatching this bug to the engineer responsible for mouse events. The test is attached to the bug report.
02-08-2006