The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Selectively Cleaning Firefox History

Small script for removing some items from Firefox history.

Firefox does a nice job of keeping my history. But not a perfect one: certain history gets in my way, and I didn’t find a good extension to automatically clean it. So I wrote a python3 script that lets me do it manually.

GitHub: Gist: clean_places.py: Python 3 script to manually remove some Firefox history items.

#!/usr/bin/python3

# The queries operate only if either:
#  * There are more than 10 visits (for things like my mail, which only bug me
#    once they are trying to clog up my new tab page)
#  * They are > 10 days old (for things like searches; recent searches aren't
#    a big problem; old searches are).

# This should be run only if Firefox is shut down (and I mean really; you
# don't want to corrupt your DB because it was hung!)

# Also, take care about your queries!

import datetime
import sqlite3
import time


PLACES_DB = "/EDITME/path/to/places.sqlite"

conn = sqlite3.connect(PLACES_DB)

cursor = conn.cursor()

select_statement = """select url from moz_places
                      where url like :query and
                      (last_visit_date < :ten_days_ago or
                       visit_count > 10)"""

delete_statement = """delete from moz_places
                      where url like :query and
                      (last_visit_date < :ten_days_ago or
                       visit_count > 10)"""

# The time stored in the DB is in UTC, so we need to be consistent.
old_time_dt = datetime.datetime.utcnow() - datetime.timedelta(days=10)
raw_time = time.mktime(old_time_dt.timetuple())
ten_days_ago = int(raw_time * 1000000)

queries = ["%localhost/roundcube/?%", # Round Cube
           "%.google.com/search?%", # Google Search
          ]

# Set to True if you want to preview what would be deleted
TEST_MODE = False

if TEST_MODE:
    statement = select_statement
else:
    statement = delete_statement

for query in queries:
    variable_bindings = {"query": query, "ten_days_ago": ten_days_ago}
    cursor.execute(statement, variable_bindings)
    if TEST_MODE:
        for row in cursor:
            print(row['url'])

if not TEST_MODE:
    print("Deleted {} rows.".format(conn.total_changes))

conn.commit()
cursor.close()

To use it you first shut down Firefox. You should make sure it’s really shut down, as you don’t want to try to modify the database while something else is. If you want to be extra paranoid, make a fresh backup your places.sqlite file.

You need to edit the PLACES_DB variable to point to your places.sqlite file. It’s usually somewhere like: /home/YOUR_USER/.mozilla/firefox/YOUR_PROFILE_FOLDER/places.sqlite.

You need to edit your query strings (queries variable). Use % as a wildcard match.

You should set TEST_MODE to True and run the script once to make sure it’s hitting your targets. The two statements are the same except one is a SELECT and the other a DELETE.

TEST_MODE will simply print what the script would delete.

If you’re satisfied, you can turn TEST_MODE off and let it rip.

If you’re adventurous you can install the sqlite3 command line tool and open the database and explore. Note that you should also ensure Firefox is not running (at least not on the same profile) when opening your places.sqlite in sqlite3.

Firefox 5 & New Release Velocity

There’s been a lot of discussion since Firefox 5 was released about the downsides of the new release cycle. There are a number of things that can be done to improve the situation.

Firefox 5 was released this past week, and it’s raised a lot of concerns.  The two biggest (discounting people who care about version numbers) are enterprise support and add-on compatibility.

Enterprise Deployment

Enterprise Information Technology departments go through a lot to keep up with the computing environments that their institutions rely on.  They are one of the major workhorses of the economy and will remain so for the foreseeable future.

To deploy something like a web browser, they must test the browser rigorously to ensure that it meets their needs without introducing any new problems.  They must also spend time educating their users so that users can make the best use of the technology without being stuck on use issues.

The concern raised by the new release cycles is that enterprises will not have adequate time to fully vet the releases, and that coupled with the loss of support for old versions makes the future of Firefox in the enterprise shaky at best.

Bugs in the Enterprise

The first issue worth considering is whether some of the hurdles that they face in deploying a more rapidly evolving piece of software represent problems in their own processes.  This is undoubtedly true for some enterprises, and third parties should not bend over backwards to work around bugs with the end-user unless they are being directly compensated to do so.

Anecdotally, the web developers that charge extra for IE 6 support fit the bill for working around the institutional bugs.

By deciding to fix their own internal bugs, they can already be better off, even without a better browser.  But they can also be proactive.

Going Along for the Ride

In addition to fixing their own internal bugs, the enterprise should look at the new release cycles objectively and use the differences in how the browser is progressing to their own advantage.  That means keeping a subset of users on the Beta channel.

That accomplishes two tasks:

  1. They keep up-to-date on the changes coming that impact them directly, including things like packaging changes.
  2. They keep up-to-date with changes impacting users, including educational needs and bugs in their intrawebs.

So the enterprise can improve their own deployment strategy, but they can also choose to be more involved with browser development itself.

Building Bridges

The enterprise has a choice to partner with the community and with other enterprises to build the tools and make the changes to the browser that better-enable their deployments.

In the past there have been efforts to create such tools, but many have gone into disuse over time and would need substantial rekindling.  It’s hard to blame Mozilla for that, when the tools were made by third parties that wanted to build the effort, but if the community gathers around new tools, it’s conceivable that some level of support can be had from Mozilla.

The other side of this is fixing the bug in the Windows world, whereby everyone is on her own to package such software.  If I ran an IT department on any of the Linux distributions, I would have most of my work done for me by virtue of existing packages to enhance or modify.

Indeed, the brilliance of the distribution model that Linux represents enables me to download any of the free software on my computer right now, make a few changes, and then have a working package with my changes in place.

The enterprises can choose to go down this path and build tools that will enhance Firefox deployment, as well as other deployments in their futures.

Oops, Add-ons

The other big issue with the new cycles is with add-ons.  Mozilla wants some users on the pre-stable channels, but it’s hard to justify giving up extensions to do so.

The good news is that the folks that work on the infrastructure of the add-ons site, Mozilla: Add-ons are working to improve things already.

The better news is that add-on authors have the opportunity to upkeep their add-ons more easily, as the differences between browser versions are less steep (though more frequent).

But a little more can be done.  One change worth considering is the ability to inform users via the add-ons manager, what versions their current add-ons are compatible with.

Another would be some kind of channel adviser.  This would let them get a recommendation based on their installed add-ons, for which channels suit them.  If their add-ons aren’t updated frequently enough, they would be told that they might be better off not going too close to the bleeding edge.

What’s in a name? Version numbers as names

There’s a warm feeling to know that this humble blog is accessible to users over IPv6. For now I can only wait for the day that I can actually get to it over IPv6 myself.

What’s in a name? that which we call a rose
By any other name would smell as sweet;

— William Shakespeare, Romeo and Juliet

In practically every discussion I’ve seen of Firefox’s new accelerated release cycles the topic of the version numbers stands prominent.  People have repeatedly claimed that it’s some sort of half-assed ploy to raise the version number to improve marketing.  I find that quite misguided, as I see the great promise the new development plan has for making Firefox the best browser it can be.

But people get bent out of shape over versioning, for whatever reason.  Though in this case the focus has been on the marketing angle, Linux has had heated discussions before regarding their versioning scheme.  And TeX just keeps on approaching Pi as its versioning scheme.

It’s just a name, and the only real rule that’s commonly followed is that the version should always be an increasing value (mainly because it’s good for programmatic comparison purposes).

Shakespeare was dead on in the famous speech by Juliet regarding the disputes that names cause.

Hell, the Internet Protocol simply skipped version 5, as ECMAScript skipped version 4.

Oh, which reminds me:

  1. APNIC (the Asian/Pacific Network Information Centre) is almost out of IPv4 addresses, meaning that for practical purposes all new allocations will be of IPv6 addresses and it’s time for the world to move on.
  2. Thanks to the awesomeness that hosts this blog, it now has a AAAA record (ie, an IPv6 address).

There’s a warm feeling to know that this humble blog is accessible to users over IPv6.  For now I can only wait for the day that I can actually get to it over IPv6 myself.