Bug 36665

Created attachment 11896 [details]
Test case to reproduce

Created attachment 11897 [details]
Thread dump at the moment of waiting

What we see on 1.4.2 is right behavior - cursor should not stop all 
of the sudden because jemmy is waiting for the queue to be empty. :) 
 
This is an event fired by cursor blinking: 
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@6a21b2,notifier=null,catchExceptions=false,when=1066708032136] 
on sun.awt.motif.MToolkit@10a5c37 
 
That event is posted both on 1.4.2 _and_ 1.4.1 (only if jemmy is not 
waiting for the queue to be empty). 
 
This last thing is wrong - coursor should've been blinkingon 1.4.1. 
And so, on 1.4.1 this test should be failing too. 
 
So, I do not consider this a bug. Closing the issue as invalid. If 
you want me to make it failing on 1.4.1, let me know. :| 
Right answer, most probably, would infolve different priorities for 
different event types. 
 
As for workaround, what we, clearly want here, is to ignore 
InvocationEvent, so, right approach would consist in using of 
EventTool class - it may be used for such stabilization. 
 

If "new QueueTool().waitEmpty(500);" has worked reliably on JDK1.4.1
then it should work the same way on JDK1.4.2. If it doesn't work, it
is regression in Jemmy for me. I don't know why is the difference
between 1.4.1 and 1.4.2 but to make it work we should filter
InvocationEvents from Timer, shoudn't we?
So, what are the possibilities:

1) Fix Jemmy to filter Timer events.
2) Recommend Jemmy users to not use QueueTool at all and use "new
EventTool().waitNoEvent(xxx);" instead

I would prefer 1).

Under "regression", we regularly mean that code was changed in a way 
that something, which was working before, is not working anymore. 
Code _was not_ changed, so we do not have a _regression_ here. 
Well, you may consider it a regression in java, since java code is 
what was changed, but I do not think you are talking about that. 
We may only talk about incompatibility. Well, that's true, obviously. 
 
And no, we should not filter timer event out. We had this discussions 
in the past, if you remember, the answer is no. 
 
The whole point on QueueTool class, is to realize that _nothing_ is 
happening to GUI. Timer events (and InvocationEvent in general),  
just like events of other types, can be used to update GUI.  
Problem with timer posts is mentioned several times in Jemmy doc,  
even though the doc is very old now. 
 
Back then, after the discussion, I created EventTool (it was created 
from Adam's code, if I recall it). This _is_ the tool if you want to 
check certain event types. And, BTW, remeber that no InvocationEvent 
can be caught by any AWTListener added by Toolkit.addAWTListener. 
 
Talking about this particular case, though, I would simply decrease 
time for the queue to be empty to some value to be less than  
cursor blinking rate. 
 
If you want to use EventTool after editor-opening operations, that is  
fine too. We are talking not about just any timer operation here, 
but about cursor blinking, right? 
 
 
Couple of facts for the closing: 
QueueTool _could not_ be rewritten to ignore one tipe of events - 
it would be EventTool. We may take it ofline, if you wish. 
 
I _have no idea_ how to create a workaround for 1.4.2, and I doubt it 
is possible. I suspect that difference is in event priorities, which 
we have not access to, from public API. 
 

OK, I will recommend to our users to not use QueueTool and use
EventTool istead, if they need something like that.
I agree to close this issue.

It is as designed, so nothing will be changed in Jemmy.

Closing.