Skip to main content

Remove Hidden Fedora Bookmarks in Firefox

My current daily driver is Fedora Silverblue combined with Firefox.

It’s a fantastic setup, but there’s a catch: Fedora websites kept showing up in my address bar suggestions. For example, if I typed “get”, Firefox would immediately suggest “getfedora.com.” It was quite annoying and surprisingly difficult to remove. Today, I finally decided to fix it once and for all.

My first thought was to simply remove the fedora-bookmarks package, which introduces these bookmarks in the first place.

However, the suggestions were still there! After exploring the Firefox settings, I realized these autocomplete suggestions were coming from saved bookmarks. But I don’t have those bookmarks!

By checking the Firefox Browser Console (not the web developer console) and using PlacesUtils, I verified that there were still many hidden bookmarks pointing to Fedora websites. Interestingly, these bookmarks were tagged. While the tags themselves were visible in the standard Firefox bookmark manager, the actual Fedora bookmarks were completely hidden.

I tried using the PlacesUtils API to remove them, but it failed, throwing an error that the database was read-only. Also tried about:support -> Places Database -> Verify Integrity, which didn’t work either.

Left with no other options, I had to directly delete them from the places.sqlite database. If you’re running into the same stubborn issue, here are the instructions.

Warning:

  • These steps will delete all tags and all tagged bookmarks, including your user-defined ones. This was a safe route for me because I don’t use the tagging feature, but proceed with caution!
  • The scripts below assume a specific version of the database schema, which might change in future Firefox releases.

1. Open the Database

Close Firefox, enter the Firefox profile directory and open the database using a temporary SQLite container:

podman run -it --rm -v ./places.sqlite:/places.sqlite:rw,Z alpine/sqlite /places.sqlite

2. List and Verify

Before deleting anything, list and verify all tagged bookmarks so you know exactly what is going to be removed:

SELECT 
  b1.title AS tag_name,
  p.title AS page_title,
  p.url AS actual_url
FROM moz_bookmarks b2
JOIN moz_bookmarks b1 ON b2.parent = b1.id
JOIN moz_places p ON b2.fk = p.id
WHERE b1.parent = (SELECT id FROM moz_bookmarks WHERE guid = 'tags________')
  AND b2.type = 1
ORDER BY tag_name, page_title;

3. Clean up the Database

Run the following transaction to safely delete the tagged bookmarks, remove the tags, and clean up the database:

BEGIN TRANSACTION;

-- 1. Store the internal URL IDs (fk) associated with the items inside your tags
CREATE TEMP TABLE target_urls AS
SELECT DISTINCT fk 
FROM moz_bookmarks 
WHERE type = 1 
  AND parent IN (
    SELECT id FROM moz_bookmarks WHERE parent = (SELECT id FROM moz_bookmarks WHERE guid = 'tags________')
  );

-- 2. Delete ALL bookmarks pointing to those URLs (this removes them from Toolbar, Menu, AND Tags)
DELETE FROM moz_bookmarks 
WHERE fk IN (SELECT fk FROM target_urls);

-- 3. Delete the tag folders themselves (since we just emptied them)
DELETE FROM moz_bookmarks 
WHERE parent = (SELECT id FROM moz_bookmarks WHERE guid = 'tags________');

-- 4. Delete the actual URLs from the core places table
DELETE FROM moz_places 
WHERE id IN (SELECT fk FROM target_urls);

-- 5. Clean up the temporary table
DROP TABLE target_urls;

COMMIT;

-- Reclaim disk space and rebuild indices
VACUUM;

Comments

Popular posts from this blog

A Rocky Migration: Moving from docker-compose to Podman and gVisor

I've been running a few containers for several years. They were all running under rootless Docker with a single user. Initially, I planned to  migrate the containers to VMs , but I couldn't get a stable workflow after about two months of effort. Later,  gVisor caught my attention , and I decided to migrate to Podman with gVisor instead. The new plan is to run each container with  --userns=auto  and use Quadlet for systemd integration. This approach provides better isolation and makes writing firewall rules easier. I'm now close to migrating all my containers. Here are a couple of rough edges I'd like to share. Network Layout I compared  various networking options  and spent a few hours trying the one-interface-per-group approach before giving up. I settled on a single macvlan network and decided to use static IP addresses for my containers. To prevent a randomly assigned IP address from conflicting with a predefined one, I allocated a large IP range for my ...

Fix Google Security Code

Google Security Code (http://g.co/sc) is one type of 2-step verification. This is particularly useful when security keys and passkeys are not available. I have been using it in my LXC containers, until today I found out that it stopped working. It just kept saying "The code is invalid". It is easy to rule out some factors: The code works on other browsers on my laptop. The code works on other devices that are directly connected to the router. So it appears that Google also checks IP addresses besides the security code. Recently I have IPv6 enabled, so most devices that are directly connected to the router have both IPv4 and IPv6 addresses. But  I only enabled IPv4 for my LXC containers. So I guess when a code is generated by device A and used by device B, Google should be able to check that device A and device B are closely located. But in my case, IPv6 address appears on device A but not on device B, which may look suspicious. To fix the problem, I just needed to disable IPv...

Exploring Immutable Distros and Declarative Management

My current server setup, based on Debian Stable and Docker, has served me reliably for years. It's stable, familiar, and gets the job done. However, an intriguing article I revisited recently about Fedora CoreOS, rpm-ostree, and OSTree native containers sparked my curiosity and sent me down a rabbit hole exploring alternative approaches to system management. Could there be a better way? Core Goals & Requirements Before diving into new technologies, I wanted to define what "better" means for my use case: The base operating system must update automatically and reliably. Hosted services (applications) should be updatable either automatically or manually, depending on the service. Configuration and data files need to be easy to modify, and crucially, automatically tracked and backed up. Current Setup: Debian Stable + Docker My current infrastructure consists of several servers, all running Debian Stable. System Updates are andled automatically via unattended-upgrades. Se...