On Tue, 14 Dec 2021 05:44:17 GMT, Prasanta Sadhukhan <psadhuk...@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. If it is not a problem now can we close this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/6826
