Working set context menu pops closed when right-clicking file that hasn't been opened yet

[peterflynn]

1. Place several files in the working set
2. Restart Brackets
3. Right-click a working set entry that hasn't been viewed in the editor yet

Result:
Context menu appears briefly, then closes again.

Expected:
Context menu stays open.

Workaround:
Right-click it again.

[peterflynn]

This also happens when right-clicking files in the project tree (if they are not open in an editor, i.e. not in the working set and not currently selected).

[RaymondLim]

I can't reproduce it on Win7. So must be a mac only issue.

[peterflynn]

I can repro on WinXP. I'm guessing it depends on how quickly the file is opened (try with a larger file, perhaps, if you're on a faster system?).

[pthiess]

Reviewed might be related to the popup management bug #1381. In Trello Card 643, closing.

[pthiess]

Re-opend since we want to keep issues visible if not ECR.

[peterflynn]

So here's how the bug plays out:

1. Right mousedown causes WorkingSetView to ask to open the document (via event.which !== 1 check in _reorderListItem() calling drop())
2. We begin loading the document from disk
3. Right mouseup followed by contextmenu event. Context menu is popped open.
4. Done loading the document; currentDocumentChange fires
5. In response, ProjectManager._redraw() is run three times. Evidently in order to "reposition the selection triangle," it forcibly triggers a scroll event on the file tree.
6. Whenever scroll occurs on the file tree, ProjectManager calls Menus.closeAll() -- snapping the context menu shut again.

In scenarios where the disk is fast or the file was already loaded, currentDocumentChange occurs before mouseup and thus the context menu opens after closeAll().

Seems like ths ideal fix is, don't fake a scroll event to trigger updating the triangle position. Barring that, we could detect fake scroll events and only call closeAll() when a real user-driven scroll has occurred.

[peterflynn]

Actually, there's a subtler bug here too: in the interval where the context menu has been opened but the document isn't yet loaded, the tree selection still lies on the old item. This means that if you manage to click a context menu command during that time, it will actually apply to the wrong file.

Probably near-impossible with our current local-disk APIs, but in browser with a network backend this could be a real problem. Along with many other similar bugs we have lurking -- so we should probably just spin that off as a separate issue.