#10574 Adjust file tree click behavior, don't collapse parent folder

[mellolikejello]

Issue #10574 - Clicking to the left of filename can collapse parent folder

Observed that clicking in the padding of a parent ul tag (positioned to the left of the span/a/ins tags containing filenames/icons) would collapse the parent folder.

Solution: Ignore ul tag clicks. When a user intends to click on a parent folder, clicks are sent from span/a/ins tags.

Test Cases:
[action] --> [result]

click parent folder icon --> toggles open/close
click parent folder title --> toggles open/close
click nested folder icon --> toggles open/close
click nested folder title --> toggles open/close
click to the left of nested folder icon --> no result action (previous behavior would close parent folder)
click filename --> select file
click to the left of filename --> no result action (previous behavior would close parent folder)

[busykai]

@nethip, @mellolikejello this change does not sound quite right, it's inconsistent with the previous behavior. with this to expand/collapse folder you'd have to click on little triangle whereas before you could click on the folder. a better solution could be ignoring the click past the line or changing the box model for the tree.

[nethip]

@busykai All the behaviors which you mentioned above, remain intact. Even with this change clicking on project folder will toggle open/close. What this PR fixes is, if the click happens in the padding area of the ul, handleClick() this will now make sure not to fold the parent folder. Am I missing anything here?

[nethip]

@busykai @mellolikejello I did some unit testing around with this fix and it takes away the annoying parent folding bug. One area I would like to see improved is that when a click happens onto the left of a file name(not folder), the file should get selected. Right now the selection happens if the click is on the file name or onto the right of the file name. @mellolikejello It would be great if you can fix this.

[busykai]

@nethip, you're right, the folder itself is actually li, ins and span. ul is the expanded area only. still, this fix is more a workaround than a proper fix. if we change the layout of the tree, it would be hard to recall the === "ul" has to be changed as well. when the issue you mention (there's a space where at the level of a file clicking on which does not select it) is fixed, change introduced in this PR should becomes unneeded.

[nethip]

@busykai yeah I agree with you this is just a work around and over a course of time this becomes hard to manage. @mellolikejello Do you think there is another proper way of fixing this? Maybe a way to not listen to clicks from ul padded area.