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

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

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?

Thanks for checking this :slight_smile:

When using the page picker

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

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

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

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

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.

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:

That’s the image version:

zefhemel/silverbullet:edge@sha256:286bfd389581dda6a19bab8d7153989645c20a1b2239d8e0e6c1c8ef75c54b7f

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)

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.

1 Like

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

1 Like

I think I already found it.

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

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.

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

Yes, that sounds right.

lol yeah thats what you already said woops

Thanks folks for looking into this.
And sorry for giving you more work due to finding this weird ā€œbugā€ :wink:

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

1 Like

No problem, I created the bug …

Anyway, this should fix it once merged

1 Like