`this` refers to the active file, rather than the base itself

Bug reports
1

Steps to reproduce

  1. In one folder, create a base with the following filters:

    filters:
  and:
    - file.folder == this.file.folder
    - file != this.file

  2. Split the tab, and, in the new pane, open a file located in a different folder

Did you follow the troubleshooting guide? [Y/N]

Y

Expected result

Base lists files that are located in the same folder as itself (as the keyword this implies)

Actual result

Base shows files that are located in the same folder as whichever file is currently in focus

Environment

SYSTEM INFO:
Obsidian version: 1.12.7
Installer version: 1.12.7
Operating system: #1 SMP PREEMPT_DYNAMIC Debian 6.12.74-2 (2026-03-08) 6.12.74+deb13+1-amd64
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: Obsidian gruvbox 0.2.1
Snippets enabled: 1
Restricted mode: off
Plugins installed: 7
Plugins enabled: 7
1: Git v2.37.1
2: Outliner v4.10.0
3: Quick Tagger v2.2.3
4: Tag Wrangler v0.6.4
5: ABC Music Notation v1.6.1
6: Dataview v0.5.68
7: Discord Message Formatter v1.5

Additional information

My debug information was copied from the latest AppImage, but this bug occurs in the Flatpak version, and the sandbox, too. here are some screenshots:

image
image1138×797 53.2 KB

the base 10.base, showing files as intended

image
image1134×839 107 KB

the base 10.base erroneously listing files from Recipes/Sweets, as I currently have Ice cream.md focused instead of 10.base

I feel like this behavior could still be useful, maybe accessed with the keyword active rather than this… but, for now, it seems to behaving in a way that I wouldn’t expect

2

What the this variable refers to depends on its context. So this should be the intended behavior I think. See Bases syntax - Obsidian Help

3

I think bugbard is getting at this:

When the base is opened in main content area, this points to properties of the base file itself. For example, using this.file.folder returns the folder path where the base is located.

So if the .base is focused and the only tab open, all fine, but if there’s another main tab group open (not in a sidebar) and that tab is focused, the results of the .base change.

1 Like
4

Ah yes, I see what you mean.

I rarely open bases with this in a main tab (mostly using the sidebar), but as far as I remember, it has always been this way, so the documentation has probably never reflected the actual behaviour. This means correcting it now could break existing workflows.

The idea of introducing additional objects like this, such as active or base, has come up several times in the forum. So if this will be corrected, it might make sense to do so alongside the introduction of such objects.

5

ahh yes! this is what I meant to convey, apologies for the confusion

I read in the docs that this behavior is intended when a base is placed in a sidebar, but I think it’s unintentional that it also occurs in the main content area, when you are working with split tabs.

a quick test reveals that this also occurs when you have a document focused in your sidebar, while a base is open in the main content area:

image
image1080×710 84.7 KB

from the way things look right now, it looks like this always refers to the active document, no matter where the base is located … if changing its behavior could break workflows, then perhaps it could retroactively be renamed to active, somehow?

6

what you see is correct, I’ll clarify/rewrite the docs and maybe write a FR myself.

1 Like