From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32014 invoked by alias); 25 Sep 2007 19:45:40 -0000 Received: (qmail 32006 invoked by uid 22791); 25 Sep 2007 19:45:39 -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:45: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 l8PJjRuc018591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 15:45: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 l8PJjRdK013311; Tue, 25 Sep 2007 15:45:27 -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 l8PJjQjG026285; Tue, 25 Sep 2007 15:45:26 -0400 Message-ID: <46F96572.70502@redhat.com> Date: Tue, 25 Sep 2007 19:45: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> <46F9613B.20704@redhat.com> <4f2ee4520709251237x4848f9e3tce7ebdb67664b1db@mail.gmail.com> In-Reply-To: <4f2ee4520709251237x4848f9e3tce7ebdb67664b1db@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/msg00036.txt.bz2 Steve McKay☄ wrote: >> 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. >> > > That's not my experience. I removed the explicit dispatch lines, then > added code to make sure the window is created and focused before the > test begins. After that, the test basically works. There appear to be > occasional deadlocks, so my thread management is wonky, but the basics > work as expected. > Great! If it works, feel free to change the test. I am obviously doing something incorrectly on my end. Lillian > >> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>> >>> >> > > >