Fixed: Issue: #2761 Project tree selection is incorrect after opening a file by means other than sidebar

[WebsiteDeveloper]

Fixed: Issue: #2761 Project tree selection is incorrect after opening a file by means other than sidebar by adding a call to the show in Tree method to select the opened file

[redmunds]

Sorry for taking so long to get to this one. Everything seems to work, except for one piece. The file that get highlighted in the project tree by selecting a result from the Find in Files panel is only partially highlighted. The text color is correctly changed to white, but the dark background rectangle (including the white triangle/arrow) is not drawn. Can you take a look at that?

[WebsiteDeveloper]

it looks like this only happens if a file in the projectTree is selected, if you first select a file in the working tree it draws the rectangle and the triangle right

[WebsiteDeveloper]

@redmunds i finally found the reason for the incomplete drawing, it seems, that the old node would still stay selected somehow, so i had to deselect all nodes at first.

[redmunds]

That fixes some case, but I am still seeing the problem in this case:

1. Remove all files from working set, close all folders in project tree, shutdown Brackets
2. Restart Brackets and don't open any files
3. Run Find in Files and leave results panel open
4. Single-click on a file that has not yet been opened (e.g. brackets.js) so it shows in editor, but is not in working set.
5. Select an entry from results panel for a file that has not yet been opened and that is in a subfolder that has not yet been opened.

Note: it does not seem to matter which order steps 3 and 4 are executed.

Results
The folder containing the file name selected from results panel is opened, and the file name is displayed with highlighted text color (white), but dark background rectangle is not drawn. This file is briefly displayed in the editor, but the editor then switches back to the original file selected in step 4. The dark background rectangle is not drawn behind either (or any other) file.

Note that if you select a second entry in results panel for same file, the background rectangle is now drawn (which I'm guessing is related to the fact that the file has already been opened).

[WebsiteDeveloper]

@redmunds it seems i accidentialy deleted the second parameter of the _redraw method so that it didn't fire a selection changed event.

[redmunds]

I'm still seeing the problem using my the recipe I posted yesterday. I played around with the recipe some more and it's actually worse than I originally reported! Not only is the file selected in the results panel not fully shown as selected in the file tree, the editor switches back to the first selected file (which is also not fully selected) ! I'll update my comment above.

What OS have you tested in on? I am seeing it on Windows 7 and Mac 10.8.

Are you building your own brackets-shell? If so, be sure it's up-to-date. If not, which build are you using?

[WebsiteDeveloper]

interestingly i now also see this issue, seems weird i'll look into it something further

[redmunds]

@WebsiteDeveloper Where are we with this pull request?

[WebsiteDeveloper]

actually i'm still investigating but i currently have no real fix, i would like to keep this open and look if i get a fix in this sprint.

[WebsiteDeveloper]

@redmunds i think i finally found a fix. ;)

[redmunds]

Bernhard, Thanks for sticking with this one!

Note that I still rarely hit the "file tree selection background is not painted" case on Mac. Most of my testing was on Mac, so I'm not sure if this can also happen on Windows. I could not find a reproducible recipe. The behavior in this branch is still much better than the current behavior, so I am going to merge this code. Please watch out for this case.

Merging.

[peterflynn]

@redmunds @WebsiteDeveloper I'm a bit concerned about inconsistency here: none of the other gestures that open a file will auto-expand all its parent folders in the sidebar tree. That's also not a common feature in other editors (some IDEs have an option to consistently do this for even file-open gesture, but even then it's turned off by default in all the ones I've seen).

Also, note that this doesn't fully fix #2761, because that bug occurs for any file-open gesture that doesn't do one of [add file to working set, or involve user clicking on the tree directly].

At first glance I'm not sure why the "deselect_all" call in ProjectManager._documentSelectionFocusChange() isn't enough to prevent this bug already... but I think we should investigate a fix there instead, and back out this change to keep our UI more consistent.

[peterflynn]

I've posted a pull request #3398 that backs out the behavior change here, but fixes #2761 (for all file-open gestures).

[redmunds]

Also, note that this doesn't fully fix #2761, because that bug occurs for any file-open gesture
that doesn't do one of [add file to working set, or involve user clicking on the tree directly].

@peterflynn Please list all of the file-open gestures that should be considered and tested in issue #2761 (not here).