Page picker always opens a new browser tab when selecting certain pages (like person/Joe)

paletochen · March 18, 2025, 7:47am

System: Debian, Docker, Edge image

Hi,
I am currently facing an issue in my 2 docker instances which are also configured as PWA, and in 2 different browsers (Chrome and Firefox).

When I have the instance opened, regardless if it is as a tab, or as a PWA, and I try to open person/Joe it does open that page in a new browser tab.
That means that when I am in PWA mode, I miss the page opened (Joe) as I normally have Silverbullet PWA instance opened in a different workspace than the rest of the apps.
If i open silverbullet as a browser tab, it just creates a new tab.

I can see the same behavior in Chrome and Firefox.

Does anyone see the same?
And if not, any idea how i could resolve this?

Thanks

zef · March 18, 2025, 1:35pm

I cannot replicate this behavior. Does this happen when you navigate using the page picker or when clicking on links. And does it happen for all pages, or just pages in folders?

paletochen · March 18, 2025, 1:52pm

Thanks for checking this

When using the page picker

Funny though, only for pages inside Person folder, like Person/Joe

zef · March 18, 2025, 1:56pm

What can I say… this doesn’t happen for me. Anything special about the Person folder? Anything odd in the logs?

paletochen · March 18, 2025, 1:58pm

That’s what I am trying to figure out.
I have an emoji assigned to the pages, trying to remove them to see if that’s the issue, but it is taking a long time for my instance to update the changes

paletochen · March 18, 2025, 2:13pm

The only difference between open another page and one that opens in a new tab is the following message in the console, when it opens in a new tab:

Couldn't find plug for specified extension client.ts:1214:16

zef · March 18, 2025, 2:14pm

Ok that can actually explain it. Your literal example is Person/Joe? Not something with a . in the name?

And you are really on a recent edge build right, because there was a regression similar to this a week or so ago I remember.

paletochen · March 18, 2025, 2:20pm

I’ll force a new image right now and let you know.
person/Joe was just an example. My pages are most of them real names, including surname. But i tested with pages without spaces and it was the same behavior.
Example, a real one that I have is this one, which opens in a new tab:

paletochen · March 18, 2025, 2:23pm

That’s the image version:

zefhemel/silverbullet:edge@sha256:286bfd389581dda6a19bab8d7153989645c20a1b2239d8e0e6c1c8ef75c54b7f

paletochen · March 18, 2025, 3:07pm

I found the issue, it is related to the objectDecorators (slightly):

objectDecorators:
  - where: 'type = "person"'
    attributes:
      pageDecoration.prefix: '"🧑 "'

The problem seems to be, not really the Decorator, but what i used for it type:

If i change type: for tags: in the person’s page, it seems to work.
So i’ll try to mass change all my types: to tags: and change the Decorator.

Is it ok to have two tags: rows in the frontmatter?
Until i fix that, i may have two rows as i am mass replacing from:

type: person
tags: family

to

tags: person
tags: family

(for example)

zef · March 18, 2025, 3:19pm

Oh wow, that’s very obscure, but indeed this is likely related to the recent introduction of custom editors,.

@MrMugame — maybe something we can avoid? It’s not great to implicitly introduce new restrictions of attribute names like type. It’s not immediately obvious where this breaks, but I remember an additional type property being passed around, which is likely what’s clashing here.

@paletochen I’d expect that if you have twice the same key you either get a parse error, or the second overrides the other. You’d have to change it to list syntax, or use another term like kind for instance.

MrMugame · March 18, 2025, 3:22pm

Yeah, I‘m unsure of the top of my head where this happens, but I‘m definitely gonna look into it today or tomorrow. Should definitely not happen tho

MrMugame · March 18, 2025, 3:40pm

I think I already found it.

github.com/silverbulletmd/silverbullet

web/components/page_navigator.tsx

main


      
              aliases = aliases.concat(pageMeta.aliases);
            }
            if (aliases.length > 0) {
              description = "(a.k.a. " + aliases.join(", ") + ") ";
            }
            if (pageMeta.tags) {
              description = (description || "") +
                pageMeta.tags.map((tag) => `#${tag}`).join(" ");
            }
            options.push({
              type: "page",
              ...pageMeta,
              name: (pageMeta.pageDecoration?.prefix ?? "") + pageMeta.name,
              description,
              orderId: orderId,
              hint: pageMeta._isAspiring ? "Create page" : undefined,
              cssClass,
            });
          } else if (mode === "meta") {
            // Special behavior for #template and #meta pages
            if (pageMeta._isAspiring) {

pageMeta overwrites the type causing the navigation to not know it‘s type. Is there a good reason to spread the metadata here? A quick solution would just be to reorder these so we overwrite the user provided metadata, thats not really nice tho

zef · March 18, 2025, 3:42pm

Maybe not good, but I think some of the code elsewhere is changing the rendering based on some specific attributes like aliases, tags etc. This has all become a bit messy over time, though. Maybe good to just pass on pageMeta without the spreading, and pull data from there in other places.

MrMugame · March 18, 2025, 3:44pm

We could just do meta: pageMeta and change the code everywhere else there tag, etc is used

zef · March 18, 2025, 3:47pm

Yes, that sounds right.

MrMugame · March 18, 2025, 3:52pm

lol yeah thats what you already said woops

paletochen · March 18, 2025, 4:08pm

Thanks folks for looking into this.
And sorry for giving you more work due to finding this weird “bug”

I have solved it on my side in the meantime by changing type: to kind:

Eventually I may change it to something else, even if back to type: if it gets fixed

MrMugame · March 18, 2025, 8:43pm

No problem, I created the bug …

Anyway, this should fix it once merged