getActiveFile and context of execution for buttons

[matthewturk]

Please fill out these Check-boxes

• I checked for existing similar issues
• I checked that the plugin is up to date
• The issue persists with all other plugins and themes disabled

Plugin Version

1.4.2

This Issue Occurs on

• Windows
• Linux
• macOS
• Android
• iOS

Debug Info

I've classified this as a bug, but I'm not certain that's the appropriate place.  I'll describe below.  If this is out of scope, please feel free to close, but I wanted to share the issue here as it was a change in behavior.

Describe the Issue

At some point in the moderately recent past, there was a behavior change. I'm trying to track this down from matthewturk/obsidian-sidecar-panel#11 , but after some work I wanted to share my thoughts in case they might trigger some ideas.

The obsidian-sidecar-panel plugin creates a sidecar panel that renders markdown using the currently "active" note as its basis, rather than the note that is being rendered. The idea behind this is to have access to various metadata fields and actions and whatnot in the side, no matter where you are in the note.

At some point in a (possibly recent?) update either in Obsidian or obsidian-meta-bind, some behavior changed. Previously, when buttons were executed, the buttons were executed with the file being edited (not the sidecar file) being the one that's acted upon. Now, this seems to be somewhat different depending on the specific type of button action that's being executed. The two simplest ways to demonstrate this are in the linked bug, but they amount to either doing a command action or an updateMetadata action.

The updateMetadata action seems to use the context in which the markdown was rendered (i.e., passed to MarkdownRenderer.render) to choose which metadata to update. On the other hand, using the command plugin executes with the result of (I think) app.workspace.getActiveFile() as the active file, which breaks a fair amount of the ability to interact with the command palette on a given file. (file-explorer:reveal-active-file is the one I've been testing.)

I'm reasonably sure this is the result of a change, but after digging in to the obsidian-meta-bind-plugin source I can't figure out where or when it happened.

The reason I think it might be in scope (but of course I could be wrong!) is that I think that there's something changing with the activeLeaf when the button is clicked on. That switches the active leaf to the sidecar panel, which because it inherits from ItemView and not FileView, it returns a null. This then updates getActiveFile to pass back a new null return, rather than the "previously active file" (which I think is listed somewhere as being the right thing to return.)

Is there an obvious way to avoid switching the active file when the button is clicked on? Is that something we can control, or is this potentially just completely out of the hands of the plugin developer?

Steps to Reproduce

I'm working on reproducing this, but since it's a joint behavior between two plugins I'm still trying to simplify it.

Expected Behavior

I would like to be able to somehow not change the getActiveFile() results, or to supply a context (the same one in the markdown closure) back to the top-level call.

[mProjectsCode]

For my answer I will just assume that everything you said is right, without doing my own testing.

Meta bind always tries to use the file that is associated with the markdown. But a command will always have to get the "target" file itself, because a command has no arguments. The change of active file is done by Obsidian and there is nothing that I can or would want to (of fear of breaking other tings) do to prevent this.

[matthewturk]

@mProjectsCode That makes sense. I'll go ahead and close it; I am experimenting with shifting the active leaf without losing focus, and that may or may not cause additional downstream breakages. I appreciate your thoughts on this!