search

brackets-archive / bracketsIssues

Archive of issues in brackets.
0 stars 0 forks source link

[CLOSED] Right-clicking on a file in the project sidebar should not open it #4334

Open core-ai-bot opened 3 years ago

core-ai-bot commented 3 years ago

Issue by EvHaus Wednesday Aug 07, 2013 at 16:53 GMT Originally opened as https://github.com/adobe/brackets/issues/4690

When you right-click on a file in the project file list, it will automatically open the file and display the context menu at the same time. I think the file shouldn't be opened.

Consider the case where you want to delete a file. You right-click on it and go to "Delete" but the whole app freezes for a second while the file is loaded.... just so you can delete it.

Not to mention -- it's not a very common app behavior for context menus.

core-ai-bot commented 3 years ago

Comment by peterflynn Wednesday Aug 07, 2013 at 19:57 GMT

It would be confusing if you right-clicked one item but the menu commands applied to a completely different item (the selected one). There are two ways to solve this: (1) change selection on right click (many apps actually do this -- Brackets, Sublime, Windows folder views, OS X Finder, iTunes, etc.), or (2) have a second item-highlighting style (other than selection) that makes it clear which item the context menu applies to (a few apps do this: Outlook, Espresso, etc.).

We chose the first route I think mainly because it was simpler to implement. You could definitely make an argument for switching to the other option, though. Marking 'move to backlog' so we can create a user story for that.

core-ai-bot commented 3 years ago

Comment by njx Wednesday Aug 07, 2013 at 20:35 GMT

Actually, Finder also does the "secondary item-highlighting style" to avoid selection on context-click.

Really, though I think, the answer is that we should make our file open times faster :) I feel like it's been getting slower, although that doesn't seem to be reflected in the performance data.

core-ai-bot commented 3 years ago

Comment by peterflynn Wednesday Aug 07, 2013 at 20:53 GMT

@njx Hah, ok Finder is really inconsistent. In icon view (where I was looking), right click changes the selection. In list view and cascading list view, right click does the secondary highlighting instead. (On Windows, afaict all folder views are consistent: right click always changes the selection).

core-ai-bot commented 3 years ago

Comment by EvHaus Wednesday Aug 07, 2013 at 22:51 GMT

Neither Finder, nor Explorer actually opens the file or displays any of its contents on right-click... Even in "Detail" mode which would give you a preview of the file's content on left-click, Finder doesn't display the details of the file on right-click.

Asking to view a context menu is not the same action as actually launching the file. There are three separate events that could occur on a right-click:

1) Open the file 2) Select the file 3) Display the context menu

Usually apps either do 2 and 3, or just 3. But never 1.

core-ai-bot commented 3 years ago

Comment by njx Wednesday Aug 07, 2013 at 23:06 GMT

I think the analogy@peterflynn was drawing was to the behavior in the folder tree in Explorer. Right-clicking on a folder does select the folder and display its contents as well as opening the context menu. The issue is really about selection; if bringing up the context menu on an item changes the selection to that item, then we have to do whatever selection of that item would normally do in addition to bringing up the context menu. In the case of a file in Brackets (or Sublime), selecting the file opens it, so that's what happens in addition to the context menu showing.

That's why we would need a separate "context-menu-only" selection, so we can avoid changing the main selection and thus opening the file.

core-ai-bot commented 3 years ago

Comment by peterflynn Wednesday Aug 07, 2013 at 23:27 GMT

Right. In all the apps I'm aware of where selection opens the file, right-clicking also opens the file -- except those few apps that do non-selection highlighting (e.g. Outlook or Espresso). In Sublime, right-clicking opens the file. In Explorer, right-clicking updates the status bar and preview panes just as left-clicking does. In WebStorm, if you change your settings so that left-clicks open the file, right-clicking also opens the file. So we seem pretty consistent with everyone else here.

Again, I'm not arguing that this is the ideal behavior. I actually like the "non-selection highlight" better. That's why I marked this as 'move to backlog' so we can record this proposal as a formal user story, prioritize it, and schedule the work for some future time. I'm pretty sure we'd also accept a pull request if you're interested in working on it sooner.

core-ai-bot commented 3 years ago

Comment by EvHaus Wednesday Aug 07, 2013 at 23:29 GMT

Sounds good. Please assign to me once scheduled.

core-ai-bot commented 3 years ago

Comment by lkcampbell Friday Nov 08, 2013 at 05:36 GMT

In Sprint 33, this behavior makes it impossible to delete a non-text file. I right click to get the menu and instead I get an error dialog that says I can't open the file. When I close the dialog box, the right click menu disappears as well. I can't delete the file.

core-ai-bot commented 3 years ago

Comment by RaymondLim Friday Nov 08, 2013 at 06:55 GMT

@lkcampbell It's been that way on mac all the time and not the new behavior in sprint 33.

core-ai-bot commented 3 years ago

Comment by redmunds Monday Mar 17, 2014 at 21:40 GMT

This was unassigned, so marking "Needs Review".

core-ai-bot commented 3 years ago

Comment by njx Tuesday Apr 01, 2014 at 20:22 GMT

Marking move to backlog. The plan is to redo the file tree entirely at some point, and at that point we could make this work properly. When we deal with this issue, we should create a more general card for redoing the file tree and link to this as one of the issues to fix.

core-ai-bot commented 3 years ago

Comment by peterflynn Wednesday Apr 02, 2014 at 00:00 GMT

@njx Looks like this one may already cover it: https://trello.com/c/GXeudis8/892-distinguish-context-menu-selection-from-ordinary-selection

core-ai-bot commented 3 years ago

Comment by yfwz100 Friday Apr 18, 2014 at 05:02 GMT

Also encounter this issue when I want to implement an extension based on context menu. I think right click on the project sidebar, actually the project files tree, doesn't means that I want to select the file to preview. Instead, I expect the context menu behaviour.

core-ai-bot commented 3 years ago

Comment by njx Sunday May 18, 2014 at 22:50 GMT

This has definitely caused problems for extensions that want to operate on binary files (e.g. FTP upload) - see https://github.com/Equals182/eqFTP/issues/12 for example (though that case was already broken on Mac before we added the recent Windows binary file handling).

I was looking at the code, and I wonder if a simple solution might be to not call the jstree select_node on a right-click (in the mousedown.jstree handler), but rather to store off a temporary context-menu selection (and highlight that node with a different context-menu highlight, as we've discussed before). Then we would make ProjectManager.getSelectedItem() return that node while the context menu is open, instead of returning the node with the actual selection. I believe most of the calls to that function intend to operate on the context menu selection when invoked from the context menu, not the currently open document (they should be using DocumentManager.getCurrentDocument() if they want the latter behavior). There was one exception in FindInFiles, but I've already fixed that as part of the Replace in Files work.

The tricky thing would be knowing when to remove the special context-menu selection. We could just keep it alive during the call to the command that's chosen from the context menu (or on dismissal of the menu if no command was chosen). This could conceivably be incorrect if the command runs asynchronously and checks getSelectedItem() at some later point after the command handler has returned/resolved. I would guess, though, that most commands access it immediately during the synchronous call to the command handler (we could grep existing extensions to check this).

@peterflynn Any thoughts? I think there's some risk to this approach, but if we checked all the existing callers to see if they would work, the fix itself is pretty simple.

/cc@Equals182

core-ai-bot commented 3 years ago

Comment by peterflynn Monday Jul 07, 2014 at 20:19 GMT

Note: NJ's suggested was nominated for implementation soon and is now in the Ready column on our Kanban tracker.

core-ai-bot commented 3 years ago

Comment by ingorichter Tuesday Sep 16, 2014 at 00:34 GMT

Right click doesn't open file anymore with new file tree implementation. FBNC.

core-ai-bot commented 3 years ago

Comment by pthiess Wednesday Sep 24, 2014 at 22:30 GMT

Closing Trello card #1341 since we track this in Waffle.

core-ai-bot commented 3 years ago

Comment by peterflynn Thursday Sep 25, 2014 at 00:58 GMT

Actually, this is implemented now --@pthiess I'm going to put the FBNC tag back on and close this. We already have the main Waffle item for the project tree tracking the overall testing, so I don't think we need to put every related bug that it fixes in that state too.

core-ai-bot commented 3 years ago

Comment by njx Thursday Sep 25, 2014 at 01:08 GMT

Yay!!!