obsidian-meta-bind-plugin icon indicating copy to clipboard operation
obsidian-meta-bind-plugin copied to clipboard

Prevent hidden buttons from being unloaded from DOM

Open Graywaren opened this issue 9 months ago • 1 comments

Please fill out these Check-boxes

  • [x] I checked for existing similar feature requests
  • [x] I have read the docs and checked that the feature I am requesting is not already implemented
  • [x] My feature request consists of only one feature

Is your Feature Request related to a Problem or Annoyance?

Due to obsidian's obnoxious implementation of DOM element removal, inline buttons frequently end up sitting at "Button ID Not Found" because their linked hidden button has been removed from the DOM. Buttons can no longer be kept at the top or bottom of a note and instead must be placed as close as possible to the inline button to keep the inline button usable. This becomes impossible in certain situations and adds a lot of risk of hidden buttons being overwritten or unintentionally moved.

The specific situation I'm encountering is that I have inline buttons in some headings that auto organize things below them, however any time I fold the heading, the inline button switches to "Button ID Not Found" because all the folded content is removed.

Also, I have encountered the issue where once removed from the DOM, hidden buttons are sometimes not re-found by the inline button when scrolled back into view, causing me to have to expand the hidden button code for it to get it working again.

Describe the Feature you'd like

I'd really like if meta bind could prevent (though I believe that's technically impossible, it'd just be immediately re-adding on removal if I understood correctly from my research) the removal of hidden buttons so they could once again be kept at the top or bottom of a document or wherever else to allow inline buttons to work as they did before deferred views.

Or, I'd like inline buttons to include all the button code so there's no longer a need for a hidden button. Inline list suggester code can get quite long, so I'd happily trade the inconvenience of long inline code for the ability to have inline buttons work consistently

I'm not sure either of these things are actually possible, but it'd be fantastic if there was a way to combat the issue

Alternatives

No response

Additional Context

No response

Graywaren avatar Mar 21 '25 23:03 Graywaren

This is so rampant, at least in my vault, and persistent with all inline buttons that I've removed the few inline buttons I had surrounded by text or other elements. For my fwd & back note navigation buttons that are a button group alone on a line started rendering the them and their hidden buttons entirely within a js-engine codeblock, which seems to be working so far. Unfortunately this requires escaping the entire button code and if I'm creating the buttons in a note template, I have to escape the entire js-engine code block, which means escaping the buttons twice. So. Many. Backslashes.

If it was possible to add the functionality of writing a single meta bind button code block containing multiple buttons, which would then all be rendered as a button group that is block instead of inline that would significantly help with this problem.

The combination of that, and the ability to put a single entire button's code in an inline button would solve the problem entirely I think, since that would mean no buttons are referencing something that can be unloaded separately from themselves.

Graywaren avatar Jul 08 '25 16:07 Graywaren