[LH2888] - Right Click in Binder Changes Document

I’m using Version: Beta (1175332) 64-bit - 19 Jan 2021

When I have two editor panes open and I want to open a second document, right-clicking on the (document) buttons in the binder FIRST changes the document in the ACTIVE editor and THEN pops up a context dialog asking me what I want do.

Shouldn’t this be open the context dialog FIRST to find out what I want? Like opening the document in the OTHER editor, or the Copyholder, or something. Why the assumption that because I right-clicked, I want the document in the ACTIVE editor changed? This is an annoying behavior because I then have to look through and find the document I WAS editing and re-open it.


John Whitten


Version: Beta (1183694) 64-bit - 27 Jan 2021

Does anybody know if this bug made it to the ‘will-fix’ pile?

It makes working with side-by-side editors very clunky. If I set the binder affinity to the left or right editors (or any other combination), when I right click something else in the binder, it first changes the document in the editor and then asks what I wanted. When what I wanted was to get to the ‘open’ (context menu) item to tell it to open it in the other editor. So then I have both editors showing the same document, and I have to remember what document I was working on, go find it in the binder, and click it to get back to what I was doing.

If I set it to ‘none’ it makes all interactions with the binder/editor extra difficult.

This is VERY CLUNKY behavior (no offense intended!) and kind of a pain in the butt :slight_smile:

UNLESS – there’s a way to do it that I don’t know about…???



It doesn’t have a [LHxxxx] tag in the subject, so probably not yet.

Best way to expedite getting it assigned a bug number is to either attach a minimal project sample that shows the problem, or give a very clear set of the minimum steps someone would need to take to reliably reproduce the problem. Then other forum users can follow those steps and confirm the problem or ask for more detail, compare it to how the Mac version behaves, etc.

In many threads I’ve seen, once there is a clear way to repro and a couple of confirmations, the bug ID (and fixes) come soon thereafter. It’s not a guarantee, but it helps your chances.

@jwhitten: We have this in our TODO list for quite some time. Unfortunately the Binder selection is crucial for many Scrivener views and the desired functionality(no select on Binder right mouse click) is something which will need a substantial amount of testing after this change. We will address it at some stage, but I cannot promise a timeframe. Have in mind that Scrivener for Mac works the same at the moment.

I will say that this isn’t the desired behaviour on either platform, but it’s an artifact or limitation of the system/framework we’re building on. There are a couple of things though that you can do which might help streamline your work;

  1. Navigate > Editor > Lock in Place (also available via the editor header’s context menu) will prevent binder clicks, including right-clicks, from affecting the editor.

  2. The backward and forward navigation history buttons in the editor header, just left of the document icon, can easily jump you back to what was previously loaded in the editor, without your having to remember and find it again in the binder. These are also in the Navigate > Editor submenu and accessible via keyboard shortcut.

@MimeticMouton: This is a limitation on the Mac platform, but not on the Windows platform. It was implemented following Mac in Scrivener v1 and not easy to change at this stage of development in Scrivener v3.

In the past, Scriv for Windows had difficulty distinguishing a left click in the Binder from a left drag gesture. Thus an attempt to drag a document into Doc Bookmarks would open the doc in the default pane, requiring a locking ritual so as not to reposition Bookmarks in the process.

Fortunately the developers addressed this behavior, and now not only can we left-drag a binder item into Bookmarks, we can also drag it into the title area of the pane in which we want to view the document,

This method doesn’t substitute for all the options in the context menu, but it enables us to open a doc in the desired pane, including Copyholder and Quick Ref, without concern for which pane happens to be active, or which one our binder selection affects.

So perhaps that’s workaround #3.


@Tiho - Yes, sorry, what I meant on the Windows side was the complications of the Qt framework; it’s not a “simple fix” to change the behaviour. :slight_smile:

@jwhitten - JJSlote makes a good suggestion here too, that you may also find it more helpful or straightforward to load documents in the second editor through a different means. Drag and drop from the binder is one option; others include opening in the focussed editor via the Navigate > Go To menu, using the Go to Document menu in the editor header’s context menu, and the Quick Search in the main toolbar.

Thanks for the info!

As a suggestion… Why not simply add the new behavior and make it selectable by the user in the program settings? You could make it so it works the current way by default, and for people who are bothered by it, they can go in and change it… ??


All of that kind of bypasses the point of the nifty binder feature :slight_smile:

However, I will keep that in mind as it’s at least a workaround.


Holding the Alt key while clicking on an item in the binder will load it in the opposite editor. Will that work for what you need? (It’s not accessing the whole context menu, but if this is mainly about opening in the other editor it might cover most of your cases.)