There appears to be a bug in FileListComponent::setSelectedFile arising from a race condition. It seems there is an assumption in this method that if !directoryContentsList.isStillLoading(), then the related FileListComponent::changeListenerCallback() must have already happened. This is a false assumption.
Firstly, DirectoryContentsList::checkNextFile() clears the isSearching flag before DirectoryContentsList::useTimeSlice() calls changed() method. So it’s possible for the thread handling the DirectoryContentsList to be preempted between clearing the flag and making the callbacks.
Secondly, the callbacks are dispatched asynchronously on the main message thread. So even if the atomic flag was cleared after making the callbacks (which would cause other problems), the flag can be observed as being false before the callbacks are ever actually executed.
The result is that FileListComponent::setSelectedFile() can correctly call selectRow(), but only to have this undone by a subsequent invocation of FileListComponent::changeListenerCallback() resulting in an erroneous deselectAllRows() call.
I think the fix is to add lastDirectory = directoryContentsList.getDirectory() to FileListComponent::setSelectedFile() when the row is selected. This should be safe since, at least by contract, FileListComponent::setSelectedFile() should be called on the main message thread, and FileListComponent::changeListenerCallback() is, as mentioned above, executed on that same thread.