Multiple Stickied Toolbars Overlap when Scrolled

[MrComputron]

Description of the bug
When multiple toolbars are placed within a note (via folder-level toolbar and additional in-notw custom toolbars) scrolling down a note causes each subsequent toolbar to stack on top of previous, stopping at top of screen regardless of toolbar height.

Steps to reproduce

1. Enable toolbar for note
2. Add second + toolbars in note
3. Scroll down note until toolbars overlap and stack

Expected behavior
Expect additional toolbars to either

1. Push toolbar above off screen and take over top position; or
2. Stack overtop of above toolbar without revealing it below

Screenshots (if you think it will help)
Video or a GIF would be appreciated.

Screen_Recording_20240511_135528_Obsidian.mp4

Theme links and CSS snippets (if applicable):
Themes and CSS snippets can affect the display of the toolbar. Include any being used here to help diagnose display issues.

Plugin links (if applicable):
If you're using a specific plugin that isn't working with the toolbar, link it here.

Mobile environment (if applicable to the issue):

• Device: Samsung S23 Ultra
• OS: Android 14, O eUI 6.1
• Obsidian version: 1.5.12
• Note Toolbar version: 1.7.22

Additional context
Add any other context about the problem here.
Occurs on any theme

[chrisgurney]

Thank you @MrComputron! I'm a little surprised this didn't come up sooner. I'll have a think on the technical solution!

[MrComputron]

My pleasure. It does bring up the question of: what is the intended behavior of multiple stickied toolbars in a note?

As a user, my expectation would be that the folder-level toolbar remains stickied to top of screen, and any in-line toolbars with "sticky" get stuck to the underside of the folder-level toolbar, getting pushed off screen as new in-line toolbars are pushed up. This would allow at most 1 additional toolbar stuck beyond the folder-level (which I would expect to persist regardless of any in-line toolbars within the note)

Your - and others' - opinion may vary but that is how I would intuit the behavior of multiple stickied toolbars to be. Whether it is even feasible technically is another issue.

[chrisgurney]

@MrComputron A few questions:

1. Is the toolbar in your video a sticky toolbar with position Below Properties, or are you using the position Top (fixed)?
2. What theme are you using in the video?
3. Does this bug occur with the default theme?
4. Does this bug occur on desktop?

[MrComputron]

1. The toolbars are:
   
2. Theme is magick which is not official theme, but the behavior happens with all themes I've tested
3. It occurs with default theme as well
4. Occurs on desktop, but slightly different: Rising toolbar obscurs entirety of toolbar above horizontally, however if toolbar above takes up multiple rows, then rising toolbar only obscurs as many rows as on the rising toolbar.

[chrisgurney]

@MrComputron Thanks for the details!

What about your toolbar at the very top? Is it (1) at position Below Properties and it's got the sticky style, or (2) is it in the Top (fixed) position?

[MrComputron]

Below properties

[chrisgurney]

@MrComputron Okay thank you!

[chrisgurney]

@MrComputron I've done some thinking on this, and I'm not sure what I'll be able to do without some fancy JavaScript.

Might I suggest:

1. hiding a bunch of those labels so they don't appear specifically on mobile, or
2. position the toolbar at the Top (fixed) position on mobile.

[chrisgurney]

@MrComputron Completely unrelated, but I'll be changing the default look of the floating button on Android specifically to be a rounded square (per Google's guidelines).

Your video and the changes you made reminded me that I should do that. 😊

[MrComputron]

I changed to top-fixed which eliminates the overlap between in-line toolbars and the folder-level toolbar. In-line toolbars still overlap as they are scrolled up.

Is there a way to have only a single in-line toolbar visible at once, with subsequent toolbars pushing them off screen?

[chrisgurney]

Is there a way to have only a single in-line toolbar visible at once, with subsequent toolbars pushing them off screen?

If your main toolbar is below props and sticky, and the rest are the same height, it works optimally.

The challenge comes with varying heights that might be possible to address with some JavaScript, but I'd rather avoid it, at least for now. I struggled with similar code to try and get sticky toolbars in Reading mode working, and it was a challenge I'd rather not revisit for a while.

[chrisgurney]

@MrComputron I've been thinking about adding a setting that dictates how toolbars wrap, and if they should wrap at all.

One option might be that the toolbar is scrollable if it's too wide for the screen, and another is that the remaining items collapse down into a menu.

This would keep the toolbar at the same height, and would help with the issue you identified.

Any thoughts on that?

[MrComputron]

Hi Chris, I think that there are two primary methods of organizing the toolbar with variants or options for both:

1.Wrapping
1.1 Endless flow wrap - The most basic form of wrapping, and the current method of organizing. This will simply wrap the buttons endlessly and will automatically scale to any device size and resolution.
1.2 Directed break - This would be the same as above, however a break could be added (either as a block type or as a yes/no toggle to each additional note block). This would allow users to decide to add specific breaks to organize their toolbars. I personally prefer this extra customization

2. Single Line
2.1 Single line scroll - One of the options you mentioned and I think this is a good option to make available on an individual basis per toolbar. Particularly for users on mobile where the vertical screen real estate is more valuable. This type could also have the option to turn on the setting between desktop or mobile.
2.2 Single line with dropdown - This is another one of your suggestions and I believe it is what we were discussing some time ago as a part of the exploration of grouped and sub toolbars. I think this would be a valuable option for users to have, particularly on mobile for the same reasons as above. It would likely require more work to set up how toolbars and subtoolbars/dropdowns are designed.

I'm on the side of more options for users are better (particularly with the many different ways that people use obsidian). I think that each of the above options could easily be individually useful to any number of users (and different of the options useful to the same users in different notes, usecases, or folders).

I think No.1 endless flow wrap is obviously needed as the basic foundation to how the plugin works, however having the option to add breaks - either as an item or as a toggle for "break after" to an existing item - would be invaluable to many users.

The side scrolling options have a clear benefit to dmobile or hybrid users (myself included) but I would imagine that the simple side scrolling one would be easiest to implement as it would not require the backend to set up dropdowns, sub-toolbars, groups, etc. (although I firmly believe that being able to add toolbars to others either as a dropdown or as a simple block of tools would be very useful).

I think to come around to answering your question: I think that having the options made available to users to wrap or not would be very beneficial considering the myriad ways that users use obsidian. I would personally appreciate the ability to select how a specific toolbar is presented, whether standard automatic wrapping or side scrolling. I think the ability to add breaks would be great to have on the wrapping type, and the ability to add dropdowns to either wrapping or side scrolling.

Anyways I hope that my rambling is of some help. I'm happy to discuss options and UI and generally be a sounding board and I wish I could help more with the actual coding aspect than my coding illiteracy allows. Note Toolbar remains a member of my top 3 most useful plugins for Obsidian.

[chrisgurney]

@MrComputron Now with 1.9 released, users have the option to not wrap items specifically on mobile. Menus are also an option, but have to be manually added. Those two things might help tame longer toolbars.

I would be interested, if you try out Menu items, about what you think!

I'll be looking at adding toolbars within toolbars as Item Groups next, and am thinking of a way to optionally break those groups on to new lines, if they don't fit.

Menu separators are part of that work, so I may consider making those optional line breaks.

Thank you for all of your thoughts and support!

[MrComputron]

I have just tested out the new 'menu' option and first impressions are that I'm really impressed with the added functionality. I haven't had a chance to really try it out too much yet or dig into the different use cases and possibilities but so far very clean implementation and very good experience.

[MrComputron]

The more I use the new dropdown menu set up the happier I get.