Website Navigation Bar

[jobbautista9]

3.8.1 has been released, which fixed the bug in browser start where the Link Toolbar shows itself between the tab and navigation/address toolbars instead of the between the viewport and the current bottom toolbar (usually the bookmarks bar), when on "tabs on top" mode and the "Show Only As Needed" visibility option is selected. Thanks to Oblomov for reporting this bug in the fediverse!

Off-topic:
I wonder if we could have the TabsToolbar be actually moved in DOM via JavaScript when toggling "tabs on top" instead of solely relying on CSS in light of this issue. It seems pretty fragile to not have its position in DOM touched. Now I am also at fault here for assuming that the user will not use that toggle and not having the overlay explicitly insert the toolbar after the PersonalToolbar, but it would be nice to be able to avoid surprises like this for other add-on developers...

[moonbat]

I've been hibernating my laptop with PM running, so great to see multiple updates back to back so I can upgrade straight from 3.4

[TropaSloppa]

Hi!, very neat addon, but while using https://addons.palemoon.org/addon/toolbargrippy/ i saw that if i collapse the website navigation bar with it's grippy and then i hover over it, it doesn't show the bar name, unlike all the other bars, curiously including the one from https://addons.palemoon.org/addon/web-developers-toolbox/, so it seems that your addon isn't providing some string that the grippy addon is looking for, yeah

[jobbautista9]

Thanks for letting me know. It seems Toolbar Grippy is checking for the toolbarname attribute instead of grippytoolbartext which we already include and is the one SeaMonkey checks (or at least one of the attributes checked). I've published a 3.8.2 release now which added a toolbarname attribute to make it compatible with the add-on, as well as incremented the maximum Pale Moon version supported while at it.

EDIT: Huh, apparently toolbarname adds a context menu item for toolbar-context-menu (one of the ways to access it is by right-clicking on the tab bar's empty space), view_toolbars_popup (View => Toolbars), and appmenu_customizeMenu (appmenu button => Preferences)... Which makes it redundant because my add-on already provides its own which is a trinary menu. Maybe that's the reason grippytoolbartext is used for SeaMonkey's Website Navigation Bar instead, so that the application itself doesn't create a context menu item for the toolbar. Perhaps I will look into what to do with that in a later date (alternatively Toolbar Grippy could support grippytoolbartext too so I can remove toolbarname).

[TropaSloppa]

Wow, that was fast, thanks!... and that does seem like a problem, i opened an issue on the grippy addon's github linking to your post, hopefully he'll be able to do something, yeah

[jobbautista9]

Looks like hiding the redundant context menu item is as simple as doing a display: none against menuitem#toggle_linktoolbar in CSS. I've published version 3.8.3 that contains this workaround!