From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27779 invoked by alias); 25 Sep 2007 19:27:38 -0000 Received: (qmail 27768 invoked by uid 22791); 25 Sep 2007 19:27:37 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Sep 2007 19:27:30 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8PJRSLU012228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 15:27:28 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8PJRRpU004125; Tue, 25 Sep 2007 15:27:28 -0400 Received: from [192.168.1.3] (vpn-14-247.rdu.redhat.com [10.11.14.247]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l8PJRROm023724; Tue, 25 Sep 2007 15:27:27 -0400 Message-ID: <46F9613B.20704@redhat.com> Date: Tue, 25 Sep 2007 19:27:00 -0000 From: Lillian Angel User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?UTF-8?B?U3RldmUgTWNLYXnimIQ=?= CC: David Herron , mauve-discuss@sources.redhat.com Subject: Re: Tweaking default java.awt.Robot settings References: <4f2ee4520709241331o1a77379cudffb314dc1622914@mail.gmail.com> <46F8238C.8020606@sun.com> <4f2ee4520709241422n5ca2cf60g8d37fb76a27d4067@mail.gmail.com> <46F82F8D.6040404@sun.com> <46F95489.3080101@redhat.com> <4f2ee4520709251213q7e317229y95c93236dd74a01f@mail.gmail.com> In-Reply-To: <4f2ee4520709251213q7e317229y95c93236dd74a01f@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact mauve-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00034.txt.bz2 Steve McKay☄ wrote: >> While it might be incorrect, I am unsure how else we can determine that >> the correct key was pressed without dispatching an event. >> > > As I know understand it, when the Robot's keyPress is called, it > should make a keypress happen on your desktop. So if the myFrame > window has focus, a keyPress event would be generated, otherwise, if > your editor is focused, it'll get the key press. > That's right. If these two lines... KeyEvent e = new KeyEvent(f, KeyEvent.KEY_PRESSED, 0, 0, code, chr, KeyEvent.KEY_LOCATION_STANDARD); f.dispatchEvent(e); ...are removed, myFrame.keyDown is not called and therefore, this.key is not set. As it seems, the Robot function keyPress is not dispatching the event to the Component. Lillian > Does anyone know if Selenium uses Robot to do its poking and prodding? > > --steve > > >> Lillian >> >> >>> It appears h.check is in gnu.testlet.TestHarness and that it simply >>> does an immediate check with no waiting. The dispatchEvent call is >>> going to cause the listener to fire regardless of what's happening >>> using Robot. >>> >>> This looks like an incorrect test, and what I'd recommend is:- >>> >>> a) ditch the two lines saying KeyEvent / dispatchEvent ... they are >>> completely subverting the intent of the test >>> >>> b) insert some code so the runTest method waits for the listener to be >>> triggered. Such as a wait and notify type of semaphor. >>> >>> c) I don't know how the test guarantees runTest executes on the event >>> dispatch thread. Is the EDT as important to classpath as it is to >>> Sun's Swing? >>> >>> - David Herron >>> >>> >>> Steve McKay☄ wrote: >>> >>>> So would you recommend I ignore the test, delete it, add a comment, ...? >>>> >>>> --steve >>>> >>>> On 9/24/07, David Herron wrote: >>>> >>>> >>>>> Steve McKay☄ wrote: >>>>> >>>>> >>>>>> Hi All, >>>>>> >>>>>> I've noticed that at least some of the tests using java.awt.Robot are >>>>>> non-deterministic due to lags is the underlying window system. The >>>>>> java.awt.Component.keyPressTest, for example, fails some of the time >>>>>> (on linux, windows, linux+wine, ...). It looks like enabling >>>>>> autoWaitForIdle (waits for the awt EventQueue to be empty before >>>>>> adding new events to the queue), and setting autoDelay (pauses for an >>>>>> arbitrary period of time) to some magic number of millis well above >>>>>> zero (I use 100) significantly reduces failures. Would anyone object >>>>>> to configuring the Robot with settings like this by default? If no, >>>>>> should the config mechanism be updated to allow tweaking these >>>>>> settings? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I don't know what the classpath implementation of Robot looks like, but >>>>> I do know what Sun's Linux/Unix implementation looks like (having >>>>> written the original version). >>>>> >>>>> Generally Robot has to request the OS or X11 to synthesize the event. >>>>> On Windows there's a direct API call, while on Unix/Linux there is a >>>>> child process which ends up calling XTEST extension methods. In both >>>>> cases it means there is a nondeterministic delay due to the current >>>>> process scheduling characteristics of the given system. In other words >>>>> it depends on an external entity, who Robot cannot coerce into >>>>> performing the request within a bounded set of time. >>>>> >>>>> I think that means depending on Robot doing it's thing within a given >>>>> period of time is an invalid test. >>>>> >>>>> Robot does not add events to EventQueue but it requests the OS to >>>>> synthesize an OS-level event. >>>>> >>>>> - David Herron >>>>> >>>>> >>>>> >>>>> >>>> >>>> >> > > >