The first thing you’re probably wondering after reading the article title is, “What is Media History?” Indeed, there is no such feature when looking externally at Google Chrome. However, this is just the name of a database that is stored in Chrome’s local storage. This database stores a history of URLs on which you played an audio or video stream on, hence the name “Media”.
Now, it does not store the media files themselves, but just the length of the time played or watched, and the URL it was playing on.
So, let us see what are the high-level parts that make up the Google Chrome media history feature.
The source code for the Media History feature lies in the chromium/chrome/browser/media/history/ folder of the repository. Here, I have linked the Github mirror of the chromium repo, because it’s much easier to browse than Google’s own source listing.
The Chromium Media History feature consists of these parts:
- Contents Observer
- Images Table
- Keyed Service
- Keyed Service Factory
- Origin Table
- Playback Table
- Session Images Table
- Session Table
- Table Base
Each of these items resides in its own file and we’ll be taking a look at them one by one.
It implements the Observer pattern documented in the famous Design Patterns book by the Gang of Four. As a recap:
The observer pattern is a software design pattern in which an object, named the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.Wikipedia – Observer pattern
Here, the Media History is notifying its subscribers when new events happen. Among the possible events to listen to, are the
WebContentsDestroyed events, inherited from the WebContentsObserver parent class, which we shall cover on a later date.
Novel event methods include
MediaSessionPositionChanged which alert subscribers when those respective fields change. It has fields for whether media has ever been played on this particular WebContents object, and whether a web navigation is occurring right now to pause state updates.
These event callbacks also update any caches that have these old objects inside them.
This is an SQL table entity that saves information about images into the database. It contains a method to export images to the database and returns their ID.
The Keyed Service holds a pointer to the Store object (more on that later), which could either be at a local or remote place. Each Keyed Service also has one pointer to a Google Chrome profile.
Keyed Service objects have methods to save watch times and stats to the Store.
Keyed Service Factory
This is the Factory pattern from the Design Patterns book, applied to keyed services. As you have probably guessed, this class is in charge of creating Keyed Service objects.
It is like the Image Table but it stores URLs in SQL-like tables.
Similarly, the Playback Table exports the timestamp and watch time specifically to the data store.
Session Images Table
This is a supporting table that correlates the image ID with the session ID.
Yet another table, this one saves URLs, metadata, and the position of the media being placed.
This object contains the actual pointer to the database, as well as to each of the tables.
This is the parent class of all of the other table classes in this section. It is responsible for initializing the database member object inside the table object.
As I briefly hinted in the last section, each Table object has its own database pointer. Consequently, when you save an entry inside the Chromium Media History, it is assigned to one of these tables, and as a result, one of the databases. There is no single Media History database: It is split into several different databases for each table.
Here is a diagram of how these components of the media history connect together.