Technical Details¶

This section contains technical details for developers and for those curious about the internal workings of the extension.

Data save location¶

Most data is currently saved in localStorage (preferences are saved in storage.sync). This is done due to ease of use: localStorage is easy to access, saves data in the JSON format, and is deleted automatically by the browser when a private session ends or a user clears their site data, something that does not happen for extension storage methods. Additionally, localStorage is per-domain (technically per-origin), while the extension-focused storage methods store data globally. This gives localStorage more storage space than the extension storage methods (see next paragraph).

The downside of using localStorage is that it has a fairly limited storage capacity: storage is generally limited to around 5MiB. However, assuming that localStorage usage for a site isn't otherwise much, by basic estimates the extension should be still able to store the data for a thousand or more URLs of loop data per site. Regardless, if the limit is shown to be more easily reached, a switch could be made to IndexedDB, which has much higher storage limits compared to localStorage. IndexedDB likewise has automatic wiping of data in private sessions and when data is wiped by the user, and is per-origin like localStorage (which is admittedly less important due to the much higher storage limits, and could even be a hindrance). Currently, there are no plans to make this move, as localStorage should likely be enough in most cases and switching to IndexedDB would potentially be a lot of work.

Looping accuracy¶

The looping accuracy, how well the looping adheres to the set time sections, is limited. This is because the current video time is updated only every so often, supposedly roughly every 15 to 250 milliseconds. This can vary depending on system load, but the bottom line is that looping is not perfect because the current video time needs to be known before a decision can be made on whether a skip should be made to the next section.

Accuracy (and performance) could potentially be improved because currently, setInterval is used for querying the video time every 20 milliseconds. Changing to listening for the timeupdate event would mean that updates happen as soon as and only when the video time changes. However, using intervals works and in testing hasn't been shown to tank performance, so changing to the event listener approach isn't a priority.