RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java fails in macos12

[Sergey Bylokhov]

On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seem to be failing in macos12.0.1 (although it does not seem to affect 12.1) due to keypresses of "a", "a", "d" is not selecting "aad" but "ade" which seems to point to the fact that 2 exclusive "a" keypress are considered as 1 "a" keypress.
> Although I am not able to reroduce this issue if test is ran standalone or in JTree group, but it fails when ran as toplevel "jdk_desktop" testgroup or even whole swing test group.
> 
> Looking at text navigational algorithm probably done in JDK-4908142 (although I am not sure if this is done for that bug or subsequently revised) 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3804
> 
> it seems if a subsequent key press comes after a predefined timefactor after the previous keypress, it is considered as a fresh/new keypress and not part of ongoing string search ie, if 2nd "a" comes after the predefined timefactor from 1st "a', then seacrh algorithm will search for "ad" and not "aad" as can be seen here
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java#L3815
> 
> I am not sure why macos12 will take so long  for 2nd "a" keypress  but the logs corraborates that it does take more than "timefactor" time what is set now, which is 1000.
> 1st "a" keypress, we have time 1639400688049 lastTime 0 typedString a
> 2nd "a" keypress, we have time 1639400691150 lastTime 1639400688049 typedString a [which is diff of 3101]
> 
> So, proposed fix is to configure "Tree.timeFactor" to 5000 to workaround this macos12 issue. It pass when full desktop tests is run in macos12 and also test passes in all platforms.

Does it mean that 3.144 after the first press is a delay caused by some code in the robot?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6826