Conflicts with Banners plugin (fixed) and Hover Editor plugin

[Moyf]

Description of the bug

When I activate the Banners (beta) plugin, the page flickers... but the Banners plugin has many bugs, so I turned it off.

But with Hover Editor, When I Pressing Ctrl and move mouse cursor to a link, the toolbar would also flicker.

To Reproduce

1. Open the Note Toolbar
2. Move mosue into a link with the Modifier key

Expected behavior Do not flicker.

Screenshots (if you think it will help)

Here is my style settings, I don't know would it be helpful?

Desktop:

• OS: Windows
• Obsidian version: 1.5.11
• Note Toolbar version: 1.3.6

Additional context Though I've turned Banners off, but if that conflict could be fixed would be very nice ; )

[chrisgurney]

Thank you! Can you please add a link to the Banners plugin (and version) you're using, so I can make sure I'm looking at the specific plugin and version?

[chrisgurney]

@Moyf I believe I've duplicated the issue:

• I installed 2.0.5-beta of obsidian-banners via BRAT.
• Hovering over the toolbar triggers an overflow: hidden rule, and then flickering as the mouse moves:
  • Core Obsidian adds this rule (due to the toolbar actually being an embed block).
  • I've never experienced the flickering before, so the way the banner's being rendered is surfacing the issue.

Solution

The solution is per the CSS snippet below. I'm not 100% sure if there will be other effects as a result of this override, but I will keep an eye on it.

This fix will be in a larger beta version I should be pushing in the next few days, so as not to conflict with the Community Plugins approval process.

Here's a snippet you apply now, if you wish. I'd love to know if this fixes the problem for you!

.cg-note-toolbar-container {
    &:hover {
        overflow: inherit !important;
    }
}

[Moyf]

@Moyf I believe I've duplicated the issue: 我相信我已经重复了这个问题：

• I installed 2.0.5-beta of obsidian-banners via BRAT.我通过 BRAT 安装了黑曜石横幅的 2.0.5-beta 。
• Hovering over the toolbar triggers an overflow: hidden rule, and then flickering as the mouse moves: 将鼠标悬停在工具栏上会触发 overflow: hidden 规则，然后随着鼠标移动而闪烁：
  • Core Obsidian adds this rule (due to the toolbar actually being an embed block).Core Obsidian 添加了此规则（因为工具栏实际上是一个嵌入块）。
  • I've never experienced the flickering before, so the way the banner's being rendered is surfacing the issue.我以前从未经历过闪烁，因此横幅的渲染方式就暴露了问题。

Solution 解决方案

The solution is per the CSS snippet below. I'm not 100% sure if there will be other effects as a result of this override, but I will keep an eye on it.解决方案是根据下面的 CSS 片段。我不能 100% 确定此覆盖是否会产生其他影响，但我会密切关注。

This fix will be in larger a beta version I should be pushing in the next few days, so as not to conflict with the Community Plugins approval process.此修复程序将是一个更大的测试版，我应该在接下来的几天内推送，以免与社区插件审批流程发生冲突。

Here's a snippet you apply now, if you wish. I'd love to know if this fixes the problem for you!如果您愿意，这是您现在可以应用的片段。我很想知道这是否可以解决您的问题！

.cg-note-toolbar-container {
    &:hover {
        overflow: inherit !important;
    }
}

Thank you for your quick and detailed response, it is very helpful to me, really appreciate it!!

I've added the snippet and it seems that the plugin could work great with Banners now! 👍

---

(* Though the Hover Editor would still make it flicker

[chrisgurney]

Great! And apologies, I didn't understand that there was a second issue here. I'll see if I can reproduce.

[Moyf]

Great! And apologies, I didn't understand that there was a second issue here. I'll see if I can reproduce.

Oh no, this is my fault, I should‘ve described it more clearly! (And maybe open two different issues :P )

This is the more detailed information: The Hover Editor plugin I am using is used to enhance the default "Page Preview" feature. https://github.com/nothingislost/obsidian-hover-editor

When holding Ctrl and moving the mouse over a Note's link, it will display a floating editing window. And with the Note Toolbar, this hover preview operation also causes flickering.

[chrisgurney]

Thanks @Moyf !

OK, I'm able to reproduce and can see what's going on:

• The top toolbar is being re-drawn because the layout-change event is being fired when that popup appears.
  • I found this out after learning that Chrome DevTools lets you set a breakpoint on a DOM element when it's removed: DevTools Elements tab > right-click on toolbar element > Break on > node removal
• If I turn off the Hover Editor plugin, it's not fired.

Will continue to investigate. If I can figure out how to differentiate why the layout change event is being fired, this will be a code change, and you'll have to update to the beta.

[Moyf]

Thanks @Moyf !

OK, I'm able to reproduce and can see what's going on:

• The top toolbar is being re-drawn because the layout-change event is being fired when that popup appears.

  • I found this out after learning that Chrome DevTools lets you set a breakpoint on a DOM element when it's removed: DevTools Elements tab > right-click on toolbar element > Break on > node removal
• If I turn off the Hover Editor plugin, it's not fired.

Will continue to investigate. If I can figure out how to differentiate why the layout change event is being fired, this will be a code change, and you'll have to update to the beta.

Thank you very much, I am glad to learn this information! Looking forward to further investigation results ; )

[chrisgurney]

@Moyf So I have a hack solution working, which is to check if the current view has a popover and not to do anything if that's the case... but it does indeed feel like a hack and might lead to the toolbar not rendering for some users, in some cases.

I'm going to sleep on it to see if there might be another approach I can take here.

Thanks again for raising both of these issues. As I don't use many UI-changing plugins, they would have come up sooner or later!

[chrisgurney]

@Moyf On testing my hack, as predicted, if I pin a callout the toolbar will no longer be refreshed.

Technical Notes

I have continued to think about this problem, and made some technical notes for myself (and anybody interested):

• Using the popover being undefined as a check seems too broad a condition, at the moment. Further investigation might reveal other parts of the active view that determines if anything actually changed, requiring a new toolbar to be added.
• I do think I need to restructure how the layout change refreshes work, starting with separating out the logic that confirms whether a toolbar should be rendered, and using it as a check in the layout change listener (assuming it stays performant).
• Today, on layout change (to reading mode, I believe), the properties element isn't always rendered on time, which results in the toolbar appearing above the properties element for a brief time, before realizing it's not in the right place. My workaround was to remove the toolbar on layout change regardless, wait some microseconds, and then add it back in.
  • So far this has been fine, but when more users start installing the plugin I'm not sure what their experience might be, and I'm uncertain if that delay will actually be long enough. (A MutationObserver might be an option here.)

[chrisgurney]

@Moyf Quick update: I have a fix mostly working for the conflict with Hover Editor.

I'm going to combine it with another feature I want to get in, hopefully this week.

[chrisgurney]

@Moyf Update 2: I had a fix mostly working, but had to revert a bunch of work to get the beta released.

I'll have to continue investigating. Thank you for your patience.

[Moyf]

@Moyf Update 2: I had a fix mostly working, but had to revert a bunch of work to get the beta released.

I'll have to continue investigating. Thank you for your patience.

WOW Nice to hear it!! Thanks for your work, it's very helpful 👍🏻 I'll update it right now! ❤️️

[Moyf]

@Moyf Update 2: I had a fix mostly working, but had to revert a bunch of work to get the beta released. I'll have to continue investigating. Thank you for your patience.

WOW Nice to hear it!! Thanks for your work, it's very helpful 👍🏻 I'll update it right now! ❤️️

It works! though the toolbar itelf would flash but it would not prevent Hover Editor from showing anymore, Nice Job!

[chrisgurney]

@Moyf I'll continue to see what I can do about that flash!

[rotane]

@chrisgurney You're the man! I just stumbled upon the same comflict with Hover Editor and then found this thread. Seems you're on top of it already; i'll patiently wait for a fix :)

[ararrocks]

i have the same issue. this is also happening when just hovering over dataview links. (apparently the preview is triggered here even without the cmd/ctrl key)

[chrisgurney]

Thank you @ararrocks

The toolbars are listening for view changes, and I think what's happening is when the Hover Editor view opens, it registers as a view change and renders the toolbar for that view. Then the Note Toolbar plugin re-renders the toolbar again for the original view (currently necessary due to how/when the Properties section is rendered).

The flickering behaviour doesn't occur if the toolbar's position is Top, so you may want to try that if that works better for you.