Conflicts with Banners plugin (fixed) and Hover Editor plugin
Closed this issue · 24 comments
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
- Open the Note Toolbar
- 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 ; )
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?
@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 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! 👍
Great! And apologies, I didn't understand that there was a second issue here. I'll see if I can reproduce.
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.
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
- I found this out after learning that Chrome DevTools lets you set a breakpoint on a DOM element when it's removed:
- 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.
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 ; )
@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!
@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.)
@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.
@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 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 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!
@Moyf I'll continue to see what I can do about that flash!
@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 :)
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)
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 (fixed)
, so you may want to try that if that works better for you.
I'm experiencing this issue with hover editor active as well - my toolbar ('Below Properties', 'sticky') keeps disappearing and reappearing when I mouse over a page wikilink (currently I don't have to hold ctrl to get the popover, which is significantly better for my use case)... so you can imagine how disruptive it is for the toolbar to keep flashing in and out disappearing and redrawing 😅 the whole page keeps shifting up and down and my text is a moving target - can't click the right spot or highlight the right selection of text to save my life 😂
Glad you're already aware and are working on this - the plugin is great! Can't wait for a beta to try - I'd install BRAT literally just to try it! Good news is that changing position to 'top' and keeping 'sticky' does in fact make the problem stop, so while it's not ideal (I really like 'below properties'), it DOES help for now until a bugfix is figured out 👍
@SoTHISIsFitness @rotane @ararrocks @Moyf
I believe I finally have fixed the conflict with Hover Editor in v1.14.1
! Please try it out and let me know how it goes.
I think having a clearer head, and more months of experience, helped look at this again with a fresh perspective. Thank you for your patience!
And of course the Obsidian team just added essentially the same functionality to the app. 😅
@Moyf As originator of this ticket, let me know when you've had a chance to check it out, and I'll close this ticket.
@Moyf As originator of this ticket, let me know when you've had a chance to check it out, and I'll close this ticket.
Finally! Congratulations!
Just tested the newest version and it seems that everything works perfect!
If you have the time and interest, could you please briefly share how to fix it? Kind of curious 'bout it :D
@Moyf Ultimately the fix was just a few lines:
- Tracked the previously-loaded file on layout change, and do nothing if it's the same. This is what was causing the rapid flickering. Once this was in place, it still flickered once, but I was able to fix with the next change.
- Delayed removing/re-rendering Properties-positioned toolbars until after layout ready. Previously, when it was being done before layout ready, I think that was doing another re-render.
- I have to remove the toolbar due to how/when Obsidian renders the Properties section, and the toolbar was being duplicated. Removing it was the only fix and I haven't really figured out a reliable alternative.
- I may have been confusing layout change vs. layout ready, which I think what led my original code.
FYI we had a report that this fix caused a problem with toolbars not appearing consistently, when switching between reading/preview and source/editing modes (#164).
I think I've solved it with a similar check, by also looking at the previous ViewMode to see if it's changed.