External links from plugin settings close popout windows (due to onBeforeUnload)

Bug reports
1

Steps to reproduce

  1. Install a plugin that has documentation links in its settings. (I’ve repro’d with Agent Client and Templater)
  2. Open one or more popout windows
  3. In any window, open the plugin’s settings pane
  4. Click on a documentation link

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

Y

(Note: the issue is not specific to any one plugin: AFAICT any plugin that includes an <a href=""> link displays this behavior, and it even happens if you add a link to a core plugin page with the inspector, or remove target="blank" from an existing link (e.g. in reading mode). The issue appears to be that any links without target="blank" trigger an onBeforeUnload event in the window where the settings dialog is opened. In practice, this is impossible to repro in Obsidian without either a plugin or the inspector, but it’s not a documented requirement for plugin devs, and it makes clicking any link in a plugin view or settings tab potentially hazardous, especially given the way the main window’s quit handler works.)

Expected result

Link opens in browser (or browser view if enabled)

Actual result

All popout windows close (if clicked in main window), or active popout closes (if clicked in a popout) before the link opens.

Environment

SYSTEM INFO:
Obsidian version: v1.10.6
Installer version: v1.10.6
Operating system: Windows 10 Pro 10.0.19045
Login status: logged in
Language: en
Catalyst license: supporter
Insider build toggle: off
Live preview: on
Base theme: light
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 1
Plugins enabled: 1
1: Templater v2.18.1

RECOMMENDATIONS:
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Additional information

If the link is clicked in the main window, the bug will only happen once, as the onBeforeUnload handler disables itself thereafter. But you can repro in individual popouts as much as you like, since you’ll be doing it in a different popout each time.

It may be that plugin developers need to be informed of the need to add target=“blank” to work around this issue, but it would probably be good to have a mitigation in the app, e.g. a fallback event handler that adds the needed target="blank" when clicking on a link without one. It isn’t currently documented as a requirement, and AFAICT it’s just as problematic for links in any plugin-supplied HTML, not just their settings.

And even if the plugin devs are ultimately responsible, the appearance of Obsidian being unstable isn’t great. It took me quite a while to trace my “mysteriously closing windows” problem to “that was when I clicked a link and didn’t see my windows go away because the browser opened on top of where they were” - so most users are unlikely to realize their disappearing windows are due to a third-party plugin.

1 Like
2

Interesting.

3

Yep, just ran across a third affected plugin today: Shell Commands also has a documentation link, same problem. I now know to always open plugins’ settings in a new popout first as a workaround, so when it closes it’s no big deal. But most people aren’t gonna know what’s happening; I’m actually astonished I even figured this out because it’s normally so infrequent.

But in the last week I was fiddling with a bunch of plugins and reading their docs, so I kept getting hit by it. I initially thought it was one of the plugins until I noticed that all the plugins I use with doc links do it. From there it was a fair amount of dev console hacking to figure out what exactly was happening and why Obsidian’s own links were fine.

I’ve been looking at Electron stuff, trying to figure out if there’s an easy workaround for this short of adding the missing target=blank during e.g. a pointerdown event on a link. So far I haven’t found anything, though.

4

One more thing possibly worth noting: the problem happens even if you have the web viewer on and “open external links” enabled - it just opens the link in a new tab in your most recent window. So whatever is triggering the beforeunload event happens before the point where the link is actually opened.

Here’s some code that I’m currently experimenting with to block the issue in popout windows:

app.workspace.on("window-open", (_win, {document}) =>
    document.body.addEventListener("mousedown", e => {
        var t = e.target.closest("a")
        if (t && ! t.getAttr("target")) t.setAttr("target", "blank")
    })
)

It seems to work, even though it’s a bit inelegant. I haven’t yet tried seeing whether it works to just have one listener on the main window, nor have I done any deeper investigation as to how navigation is triggered (to see if there’s a cleaner/better way to do this that doesn’t require checking every mousedown event, while still supporting dynamic content in and out of SettingsTabs).