Funny bookmarks issue

[Graydenn]

Describe the bug In short, the display: block !important; in the .tab-throbber part of the uc-tabs.css file is causing my bookmarks to disappear.

To Reproduce Steps to reproduce the behavior:

1. Install the theme (master or latest release, either one works)
2. Add a bookmark
3. Bookmark is not there

Expected behavior Bookmark is there

Screenshots You see the AniList text and icon? When the code I mentioned above is present, it's just not there. Completely empty blue bar.

Desktop (please complete the following information):

• OS: Tested on Windows 10 and Windows 11
• Firefox update channel: Tested moth main and nightly
• Version: Bug has been here a while, currently on 98.0a1
• Build ID: 20220122214838

Additional context Maybe this bug is just for me? I'd assume you would've fixed it by now (been happening for weeks, just thought to report it now) if it was something you knew about. However, I've completely formatted my disk and reinstalled Windows and the bug hasn't been resolved by that.

[Graydenn]

Here's how it looks now that I've replaced that line.

Also, I have custom-chrome.css populated but this issue remains with the file deleted.

[aminomancer]

Are you positive your stylesheet files match mine? Sometimes people want to live edit their stylesheets in the browser toolbox and wind up editing the theme stylesheets rather than making new rules in custom-chrome.css. (That's why I put a dummy rule in the stylesheet, so it'll always be loaded in the style editor) Maybe I'm misunderstanding the bug but I can't reproduce it at all. The bookmarks toolbar looks completely normal for me. I also don't see how on earth the rule you're talking about could cause a problem with bookmark toolbar buttons, since the two have nothing to do with each other. The tab-throbber class only exists in, well, tabs. The only way I can wrap my head around it is maybe you have an old version of the stylesheet or accidentally edited it in such a way that there's a syntax error, maybe a missing bracket or something.

Formatting your disk and reinstalling Windows definitely would not resolve a CSS issue. Whatever the problem is, it's in your chrome folder. Are you using scripts? Are you using any CSS not hosted on this site? Are you sure you don't have any stylesheets that used to be on this repo but have since been deleted? The easiest way to confirm that is to just back up all your custom files (anything you added yourself), then delete your whole chrome folder, then make a new one and populate it with the files from the repo. Unfortunately there isn't a simple way to alert users when scripts are deprecated so I'm sure there are people out there using old scripts I made.

What about preferences? I have a bunch of custom preferences like userChrome.bookmarks-toolbar.icons-only. This would be important information for me to reproduce your environment. Otherwise, using the browser toolbox to see what is going on in the DOM there would be useful. Clearly there is a bookmark there, because when the bookmarks toolbar is actually empty, it shows a message there which says "For quick access, place your bookmarks here on the bookmarks toolbar." The fact that the message is not there indicates that a bookmark is there, it's just not visible. Why it's not visible is hard to say without seeing the DOM.

[aminomancer]

Also, like the instructions in the readme say, make sure you are not just copying and pasting the entire repo into your chrome folder. Specifically, you should only install the scripts that you're confident you want. They're not all part of the theme. Only the ones with a little sparkle ✨ would I consider important for the theme. Here is my personal list:

aboutCfg.uc.js
allTabsMenuExpansionPack.uc.js
appMenuAboutConfigButton.uc.js
appMenuMods.uc.js
atoolboxButton.uc.js
autocompletePopupStyler.uc.js
autoHideNavbarSupport.uc.js
backspacePanelNav.uc.js
bookmarksMenuAndButtonShortcuts.uc.js
bookmarksPopupShadowRoot.uc.js
clearDownloadsButton.uc.js
copyCurrentUrlHotkey.uc.js
customHintProvider.uc.js
debugExtensionInToolbarContextMenu.uc.js
extensionOptionsPanel.uc.js
extensionStylesheetLoader.uc.js
eyedropperButton.uc.js
findbarMods.uc.js
fixTitlebarTooltips.uc.js
floatingSidebarResizer.uc.js
fullscreenHotkey.uc.js
hideTrackingProtectionIconOnCustomNewTabPage.uc.js
letCtrlWClosePinnedTabs.uc.js
miscMods.uc.js
navbarToolbarButtonSlider.uc.js
oneClickOneOffSearchButtons.uc.js
openBookmarkInContainerTab.uc.js
openBookmarksHistoryEtcInNewTabs.uc.js
openLinkInUnloadedTab.uc.js
osDetector.uc.js
pinTabHotkey.uc.js
recentlyClosedTabsContextMenu.uc.js
removeSearchEngineAliasFormatting.uc.js
restorePreProtonArrowpanels.uc.js
restorePreProtonLibraryButton.uc.js
restorePreProtonStarButton.uc.js
restoreTabSoundButton.uc.js
screenshotPageActionButton.uc.js
scrollingOneOffs.uc.js
searchModeIndicatorIcons.uc.js
searchSelectionShortcut.uc.js
showSelectedSidebarInSwitcherPanel.uc.js
tabAnimation.uc.js
toggleMenubarHotkey.uc.js
tooltipShadowSupport.uc.js
trackingProtectionMiddleClickToggle.uc.js
unreadTabMods.uc.js
updateBannerLabels.uc.js
updateNotificationSlayer.uc.js
urlbarMods.uc.js
urlbarMouseWheelScroll.uc.js
urlbarNotificationIconsOpenStatus.uc.js
userChromeAgentAuthorSheetLoader.uc.js
userChromeDevtoolsSheetLoader.uc.js
verticalTabsPane.uc.js
windowDragHotkey.uc.js
WNPCListener.uc.js

[Graydenn]

I'm just as confused as you are. I mentioned the reset because I completely reinstalled the theme and remade my custom CSS afterwards. I'm using your recommended.js config for preferences, with no other edits.

While testing I removed the entire scripts folder and the issue was not resolved, so I skipped that.

[Graydenn]

I installed the theme from the latest commit a couple hours ago, but as far as I can tell the same happens for the last couple RELEASED versions.

[Graydenn]

Here, I've taken the liberty of recording an example video to prove I'm not going insane.

https://user-images.githubusercontent.com/42272058/150672345-9bc57052-6218-44b8-b12f-05bde8454789.mp4

[aminomancer]

Don't worry I'm sure you're not going insane. I just don't have enough information to reproduce the issue. I don't know what your preferences are, don't know what scripts you're using, don't know that your files are correct. For example, custom-chrome.css should not be 2 KB unless you modified it. Anyway, I made a brand new profile and downloaded the files from the repo. I still can't reproduce the issue. Have you tested this on a new profile? This one doesn't seem to be new.

Judging by the surrounding code, maybe it has something to do with the parentheses wrapping the @supports (-moz-bool-pref(... rule. I'm not sure why I did that, I don't normally do that. It should be fine and it isn't causing problems for me, but I removed the additional parentheses and just pushed the update. So maybe try downloading again.

[Graydenn]

Here is my custom-chrome.css, however I deleted this file during testing and the results were the same. Removing the !important also fixes the issue, however that might break your tab thing.

[Graydenn]

Alright, so I downloaded the repository as it is after your latest commit and applied that to a brand new profile (along with recommended.js) without making any changes whatsoever. The issue remains.

[aminomancer]

Well that's exactly what I did too and I still can't repro the issue. I also tried just copying the entire repo (including all the scripts simultaneously, which you're not supposed to do) to see if that could cause a problem. There's really nothing more I can do since I can't even see the problem for myself. If I were you, I would open the browser toolbox, use the inspector to find the bookmark element that's supposed to be there, and investigate what rules are applying to it (or whether it even exists in the DOM). It's one of the things I can't do for you but it's the most likely to reveal the cause. That's gonna elucidate why it's not displaying. It's gonna have some rule on it that says display: none or visibility: collapse or opacity: 0 or something capable of hiding an element. That rule is gonna have a link in the top right corner that will jump to the line in the stylesheet where that rule is. Then you can tell me what stylesheet and line number that is.

The fact that removing a completely random line from a completely unrelated stylesheet miraculously solves the problem isn't very useful, since it's clearly not possible unless there is an error in the stylesheet file or in how the stylesheet is being parsed. I mean, for one, display: block doesn't hide an element in the first place. The stylesheets are automatically linted on every commit, and I double checked it to be sure. There are no syntax errors. I don't see how there could be a Firefox bug causing this, since (presumably) we're both using the latest Nightly release and we're both testing the exact same files on brand new profiles on the same operating system.

Maybe try deleting userChrome.tabs.new-loading-spinner-animation in about:config and in user.js and see if the problem goes away? If that rule you deleted is the actual cause of the problem (rather than an idiopathic syntax or parsing error) then removing the pref should resolve it, since that rule is wrapped in a @supports block. It should not be read at all if the -moz-bool-pref function evaluates to false, as it should if the pref is not enabled. If the issue persists then we know that, even though deleting that line appears to resolve the issue, the line itself is not the cause. That already seems obvious to me just based on understanding how CSS works and that the rule cannot apply to the bookmark button or any of its ancestors.

One thing I do know about the bookmarks toolbar is that its overflow behavior is weird. I'm pretty sure there's no limit to the number of child elements it can have. Like, if your bookmarks toolbar folder (that is, the node in your places database) contains 50,000 bookmarks, then that element will have 50,000 child elements. But only a few dozen will display. There's a function that sets their visibility based on calculations about the child element's positions on the document's coordinate plane versus the position of the toolbar. If the child element overflows it's simply hidden. So there's no scrolling the toolbar, instead it overflows into the overflow menupopup opened by the chevron button. That is relevant because it's conceivable (though unlikely) that some kind of CSS could cause a change in the position of the bookmarks toolbar or of elements on the toolbar, which could change how those calculations lay out the buttons. One way I'd approach troubleshooting this is to try resizing the window, since that should trigger a reflow if there are enough bookmark buttons in the toolbar.

[aminomancer]

One thing about my tab throbber customization. It is expensive to render. In order for it to animate in and out when it appears/disappears, it needs to be constantly drawn. Which means its animation needs to be constantly running. There are a couple methods for this which you can try. They're commented out but the comments explain what to do. I don't know how this might affect other aspects of the browser. The bookmarks toolbar reflow is waiting for requestAnimationFrame() which means it's subject to painting speed. I guess it's conceivable that somehow throbbers being invisibly drawn causes a slowdown which prevents the reflow from ever happening. It seems ridiculous to me but I just don't know.

Another thing that would be useful would be knowing if this is a regression with my theme, or a Firefox regression, or neither. Does installing an old version of the theme resolve the issue? Does installing an old version of Firefox resolve it?

[aminomancer]

Oh, one other critically important thing. When you install the theme or scripts for a new profile, you should run the profile once before installing anything. The profile will be empty except for a lock file and a json file. It's on the first run that all the important stuff is generated. Then you can copy the files over. I don't think that's the likely culprit but it has caused other bugs

[aminomancer]

Edit: I uploaded some scattershot changes to the bookmarks toolbar, I don't know if they have anything to do with this, but it's worth testing.

And also, if you open the browser toolbox when this happens, there's a Console tab that will log errors in the parent process. With something like this I would expect there to be an unhandled exception or maybe a CustomizableUI error or something. So copying and pasting the console log to me may reveal something about the issue. Anyway, here's what it looks like for me with a brand new profile, copying the entire repo into the profile's chrome folder and using recommended.js as the profile's user.js file.

From startup, the bookmark button takes about 200ms to appear on the toolbar.

[Graydenn]

For starters, removing the userChrome.tabs.new-loading-spinner-animation preference from about:config and user.js also resolves the issue, showing the bookmarks again.

The theme was installed after running the profile one time, I made sure of that. Furthermore, resizing the window doesn't change anything. I was able to reveal the bookmarks toolbar overflow chevron thingy by messing with the toolbox, but it didn't contain anything.

I also tried updating to the lastest version, however that didn't resolve the issue.

Here's what I can see of the PersonalToolbar div using the toolbox. As far as I can see, it's not even loading the bookmark element. I also mentioned with every visibility-related line of CSS in the div, but nothing revealed any bookmarks. All I managed to reveal was the text that shows when no bookmarks are present.

Here's the console from that same toolbox. I can see a couple bookmark-related listings, however they seem to be JS related and since the issue persists with the entire JS folder removed I doubt this is the issue.

At this point I question if somehow something else from my computer is conflicting with Firefox somehow. No idea. I'm going to try to replicate this issue in a fresh Windows 10 virtual machine with absolutely nothing else installed except Firefox. Will report back.

[Graydenn]

Yep, that's a new one. With Firefox as the only thing installed and configured on a fresh Windows 10 virtual machine, it works great. No idea what is conflicting with Firefox.

[aminomancer]

That _onChevronPopupShowing error is definitely revealing a strange problem, that is the source of the bug. It says document.getElementById('PlacesToolbar')._placesView is undefined. There's a reference in the source code to this property possibly being undefined. That's executed from here. That property should be set at this point.

The only way I can see that not happening is if the new PlacesToolbar(...) call is never happening. Somehow it is returning before that. How could that happen? Well here's what invokes it. The #PersonalToolbar should have attribute initialized="true" but it doesn't in your screenshot, so clearly that method _realInit is either returning before line 1169, or it's never executing in the first place.

As you can see from here, Firefox is waiting for an idle dispatch before calling _realInit. The promise isn't resolved until this task is finished. It calls ChromeUtils.idleDispatch which is outside my area of expertise. But clearly this involves some low level task scheduling issue, which explains how CSS could be involved. It may ultimately be a performance issue.

[aminomancer]

Maybe check your environment variables and local group policies. Firefox has a number of env variables and policies, both documented and undocumented, that influence native code paths irrespective of user profile or even installation. That may explain why it persists between profiles and installations, yet doesn't reproduce on a fresh VM.

[Graydenn]

I think we're getting a little out of my area of expertise as well... what should I be checking for? I haven't changed any group policies and the only thing I've done in my environment variables is added one folder to my path.

[aminomancer]

I'm really not sure, that was just a wild guess. You may not have changed anything yourself, but programs you install might be able to change them. With environment variables you're generally looking for variables that start with MOZ_. With group policies there would be either a folder in the binary directory called distribution or a registry directory at <root>\Software\Policies\Mozilla\Firefox\, where root could be HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE or HKEY_USERS\*\.

I have a stronger intuition that it's not related to a setting, but rather to some kind of operating system issue with process or IO task scheduling. Which basically means your guess is as good as mine. Before investing a bunch of time in tracking down the ultimate cause, you might also want to try doing something like this, to make sure the CSS rule at least isn't applying during startup when the toolbar is initialized (add it to custom-chrome.css):

.tabbrowser-tab:not([fadein]) .tab-throbber:not([fadein]) {
    display: none !important;
}

I should probably add that to the stylesheet myself.

But in any event, this isn't a big deal. That little loading spinner is a very small detail, it's probably not worth sacrificing other aspects of your system. There are 2 approaches that stand out. 1 is to just override the display: block rule so that the throbber is truly not rendered when it's not meant to be visible. As it stands, the stylesheet makes it "display" all the time, but hides it with opacity and transform. That's because display is not an animatable property so we can't slide/fade it in smoothly if it's starting from a fully hidden state. Well, we can, but it would require javascript which would be even worse for performance due to the sheer number of tabs. But this is a very subtle effect. It doesn't really matter whether it animates. So, adding this rule might resolve it with minimal downsides:

.tabbrowser-tab .tab-throbber:not([busy], [progress]) {
    display: none !important;
}

Finally, if that doesn't work, you can always just disable the pref. Again, it's just a small optional feature. The built-in throbber icon looks fine. I only change it because I animate it, and since it's sliding horizontally when it shows/hides, it looks kinda weird to have an icon that itself oscillates horizontally. But if we're not gonna animate its hiding/showing, then we might as well keep the original throbber icon.

[aminomancer]

Wait, never mind. I think I figured out the cause. It's exactly what I thought, schedule pressure. So that first CSS rule I suggested should fix it. I will add it to the theme.

Edit: so you can just download the latest files by cloning the repo or clicking the white Download button at the top of the readme.

[Graydenn]

Well we've got the import icon now

[aminomancer]

Wtf... can you show me the DOM? What is going on to the left of the import button? It seems like there is something there since it's pushing the import button over to the right

[aminomancer]

And can you tell me about the system's hardware? Is this x86_64 or ARM64? How much system memory and video memory? Etc.

[Graydenn]

My knowledge of this kind of thing is intermittent, so I'm not entirely sure what you mean by DOM. If you mean the inspect element source-y thing, here:

Looks like personal-toolbar-empty perfectly fits in that little gap.

As for the hardware, I doubt it's a performance issue. This machine has a 5600X (x64), 16GB of memory, and a 1060 6GB graphics card.

[aminomancer]

No the personal-toolbar-empty thing should say "For quick access, place your bookmarks heron the bookmarks toolbar." I don't know why it's invisible, to determine that requires looking at the rules applying to it. The inspector has multiple columns. To the right there should be a list of rules. That's where you see what rules are applying to the element you clicked in the inspector view on the left.

[aminomancer]

Anyway, what does the console say after all this?

[Graydenn]

Yeah, it says that but the hbox there seems to be the size of the gap (aside from being hidden).

The console is saying this at the moment:

If you've got any interest in remoting in to check things for yourself, I have no problem with that.

[aminomancer]

Hmm I see, that's probably just the nowidth property then. Sure, do you have remotix agent?

[aminomancer]

If you go to chat.mozilla.org and log in with your Firefox account, you can hit the + button at the top, and type in @aminomancer:mozilla.org to find me.