1
0
mirror of https://github.com/gorhill/uBlock.git synced 2024-10-04 16:47:15 +02:00
uBlock/src/js/start.js

531 lines
18 KiB
JavaScript
Raw Normal View History

2014-06-24 00:42:43 +02:00
/*******************************************************************************
uBlock Origin - a comprehensive, efficient content blocker
Copyright (C) 2014-present Raymond Hill
2014-06-24 00:42:43 +02:00
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see {http://www.gnu.org/licenses/}.
Home: https://github.com/gorhill/uBlock
*/
/* globals browser */
2016-08-13 22:42:58 +02:00
'use strict';
2014-06-24 00:42:43 +02:00
/******************************************************************************/
import './vapi-common.js';
import './vapi-background.js';
import './vapi-background-ext.js';
/******************************************************************************/
// The following modules are loaded here until their content is better organized
import './commands.js';
import './messaging.js';
import './storage.js';
import './tab.js';
import './ublock.js';
import './utils.js';
import io from './assets.js';
import µb from './background.js';
import { filteringBehaviorChanged } from './broadcast.js';
import cacheStorage from './cachestorage.js';
import { ubolog } from './console.js';
import contextMenu from './contextmenu.js';
import lz4Codec from './lz4.js';
import { redirectEngine } from './redirect-engine.js';
import staticFilteringReverseLookup from './reverselookup.js';
import staticExtFilteringEngine from './static-ext-filtering.js';
import staticNetFilteringEngine from './static-net-filtering.js';
import webRequest from './traffic.js';
import {
permanentFirewall,
sessionFirewall,
permanentSwitches,
sessionSwitches,
permanentURLFiltering,
sessionURLFiltering,
} from './filtering-engines.js';
/******************************************************************************/
vAPI.app.onShutdown = ( ) => {
staticFilteringReverseLookup.shutdown();
io.updateStop();
staticNetFilteringEngine.reset();
staticExtFilteringEngine.reset();
sessionFirewall.reset();
permanentFirewall.reset();
sessionURLFiltering.reset();
permanentURLFiltering.reset();
sessionSwitches.reset();
permanentSwitches.reset();
};
vAPI.alarms.onAlarm.addListener(alarm => {
µb.alarmQueue.push(alarm.name);
});
/******************************************************************************/
// This is called only once, when everything has been loaded in memory after
// the extension was launched. It can be used to inject content scripts
// in already opened web pages, to remove whatever nuisance could make it to
// the web pages before uBlock was ready.
//
// https://bugzilla.mozilla.org/show_bug.cgi?id=1652925#c19
// Mind discarded tabs.
const initializeTabs = async ( ) => {
const manifest = browser.runtime.getManifest();
if ( manifest instanceof Object === false ) { return; }
const toCheck = [];
const tabIds = [];
{
const checker = { file: 'js/scriptlets/should-inject-contentscript.js' };
const tabs = await vAPI.tabs.query({ url: '<all_urls>' });
for ( const tab of tabs ) {
if ( tab.discarded === true ) { continue; }
if ( tab.status === 'unloaded' ) { continue; }
const { id, url } = tab;
µb.tabContextManager.commit(id, url);
µb.bindTabToPageStore(id, 'tabCommitted', tab);
// https://github.com/chrisaljoudi/uBlock/issues/129
// Find out whether content scripts need to be injected
// programmatically. This may be necessary for web pages which
// were loaded before uBO launched.
toCheck.push(
/^https?:\/\//.test(url)
? vAPI.tabs.executeScript(id, checker)
: false
);
tabIds.push(id);
}
}
// We do not want to block on content scripts injection
Promise.all(toCheck).then(results => {
for ( let i = 0; i < results.length; i++ ) {
const result = results[i];
if ( result.length === 0 || result[0] !== true ) { continue; }
// Inject declarative content scripts programmatically.
for ( const contentScript of manifest.content_scripts ) {
for ( const file of contentScript.js ) {
vAPI.tabs.executeScript(tabIds[i], {
file: file,
allFrames: contentScript.all_frames,
runAt: contentScript.run_at
});
}
}
}
});
2015-02-13 18:10:10 +01:00
};
2014-12-20 21:28:16 +01:00
2014-08-21 01:39:49 +02:00
/******************************************************************************/
2015-02-24 19:48:03 +01:00
// To bring older versions up to date
//
// https://www.reddit.com/r/uBlockOrigin/comments/s7c9go/
// Abort suspending network requests when uBO is merely being installed.
2015-02-24 19:48:03 +01:00
Redesign cache storage In uBO, the "cache storage" is used to save resources which can be safely discarded, though at the cost of having to fetch or recompute them again. Extension storage (browser.storage.local) is now always used as cache storage backend. This has always been the default for Chromium-based browsers. For Firefox-based browsers, IndexedDB was used as backend for cache storage, with fallback to extension storage when using Firefox in private mode by default. Extension storage is reliable since it works in all contexts, though it may not be the most performant one. To speed-up loading of resources from extension storage, uBO will now make use of Cache API storage, which will mirror content of key assets saved to extension storage. Typically loading resources from Cache API is faster than loading the same resources from the extension storage. Only resources which must be loaded in memory as fast as possible will make use of the Cache API storage layered on top of the extension storage. Compiled filter lists and memory snapshot of filtering engines (aka "selfies") will be mirrored to the Cache API storage, since these must be loaded into memory as fast as possible, and reloading filter lists from their compiled counterpart is a common operation. This new design makes it now seamless to work in permanent private mode for Firefox-based browsers, since extension storage now always contains cache-related assets. Support for IndexedDB is removed for the time being, except to support migration of cached assets the first time uBO runs with the new cache storage design. In order to easily support all choices of storage, a new serializer has been introduced, which is capable of serializing/deserializing structure-cloneable data to/from a JS string. Because of this new serializer, JS data structures can be stored directly from their native representation, and deserialized directly to their native representation from uBO's point of view, since the serialization occurs (if needed) only at the storage interface level. This new serializer simplifies many code paths where data structures such as Set, Map, TypedArray, RegExp, etc. had to be converted in a disparate manner to be able to persist them to extension storage. The new serializer supports workers and LZ4 compression. These can be configured through advanced settings. With this new layered design, it's possible to introduce more storage layers if measured as beneficial (i.e. maybe browser.storage.session) References: - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local - https://developer.mozilla.org/en-US/docs/Web/API/Cache - https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
2024-02-26 22:50:11 +01:00
const onVersionReady = async lastVersion => {
if ( lastVersion === vAPI.app.version ) { return; }
vAPI.storage.set({
version: vAPI.app.version,
versionUpdateTime: Date.now(),
});
const lastVersionInt = vAPI.app.intFromVersion(lastVersion);
// Special case: first installation
if ( lastVersionInt === 0 ) {
vAPI.net.unsuspend({ all: true, discard: true });
return;
}
// Remove cache items with obsolete names
if ( lastVersionInt < vAPI.app.intFromVersion('1.56.1b5') ) {
io.remove(`compiled/${µb.pslAssetKey}`);
io.remove('compiled/redirectEngine/resources');
io.remove('selfie/main');
}
// Since built-in resources may have changed since last version, we
// force a reload of all resources.
redirectEngine.invalidateResourcesSelfie(io);
2015-02-13 18:10:10 +01:00
};
/******************************************************************************/
2014-09-08 23:46:58 +02:00
2015-04-07 03:26:05 +02:00
// https://github.com/chrisaljoudi/uBlock/issues/226
2015-02-13 18:10:10 +01:00
// Whitelist in memory.
// Whitelist parser needs PSL to be ready.
// gorhill 2014-12-15: not anymore
//
// https://github.com/uBlockOrigin/uBlock-issues/issues/1433
// Allow admins to add their own trusted-site directives.
2015-02-13 18:10:10 +01:00
const onNetWhitelistReady = (netWhitelistRaw, adminExtra) => {
if ( typeof netWhitelistRaw === 'string' ) {
netWhitelistRaw = netWhitelistRaw.split('\n');
}
// Append admin-controlled trusted-site directives
if (
adminExtra instanceof Object &&
Array.isArray(adminExtra.trustedSiteDirectives)
) {
for ( const directive of adminExtra.trustedSiteDirectives ) {
µb.netWhitelistDefault.push(directive);
netWhitelistRaw.push(directive);
}
}
µb.netWhitelist = µb.whitelistFromArray(netWhitelistRaw);
2015-02-24 19:48:03 +01:00
µb.netWhitelistModifyTime = Date.now();
2015-02-13 18:10:10 +01:00
};
/******************************************************************************/
// User settings are in memory
const onUserSettingsReady = fetched => {
// Terminate suspended state?
const tnow = Date.now() - vAPI.T0;
if (
vAPI.Net.canSuspend() &&
fetched.suspendUntilListsAreLoaded === false
) {
vAPI.net.unsuspend({ all: true, discard: true });
ubolog(`Unsuspend network activity listener at ${tnow} ms`);
µb.supportStats.unsuspendAfter = `${tnow} ms`;
} else if (
vAPI.Net.canSuspend() === false &&
fetched.suspendUntilListsAreLoaded
) {
vAPI.net.suspend();
ubolog(`Suspend network activity listener at ${tnow} ms`);
}
// `externalLists` will be deprecated in some future, it is kept around
// for forward compatibility purpose, and should reflect the content of
// `importedLists`.
if ( Array.isArray(fetched.externalLists) ) {
fetched.externalLists = fetched.externalLists.join('\n');
vAPI.storage.set({ externalLists: fetched.externalLists });
}
if (
fetched.importedLists.length === 0 &&
fetched.externalLists !== ''
) {
fetched.importedLists =
fetched.externalLists.trim().split(/[\n\r]+/);
}
fromFetch(µb.userSettings, fetched);
2014-08-21 16:56:36 +02:00
if ( µb.privacySettingsSupported ) {
vAPI.browserSettings.set({
'hyperlinkAuditing': !µb.userSettings.hyperlinkAuditingDisabled,
'prefetching': !µb.userSettings.prefetchingDisabled,
'webrtcIPAddress': !µb.userSettings.webrtcIPAddressHidden
});
}
// https://github.com/uBlockOrigin/uBlock-issues/issues/1513
if (
vAPI.net.canUncloakCnames &&
µb.userSettings.cnameUncloakEnabled === false
) {
vAPI.net.setOptions({ cnameUncloakEnabled: false });
}
2015-02-13 18:10:10 +01:00
};
2015-02-24 00:31:29 +01:00
/******************************************************************************/
// https://bugzilla.mozilla.org/show_bug.cgi?id=1588916
// Save magic format numbers into the cache storage itself.
// https://github.com/uBlockOrigin/uBlock-issues/issues/1365
// Wait for removal of invalid cached data to be completed.
2015-02-24 19:48:03 +01:00
const onCacheSettingsReady = async (fetched = {}) => {
Redesign cache storage In uBO, the "cache storage" is used to save resources which can be safely discarded, though at the cost of having to fetch or recompute them again. Extension storage (browser.storage.local) is now always used as cache storage backend. This has always been the default for Chromium-based browsers. For Firefox-based browsers, IndexedDB was used as backend for cache storage, with fallback to extension storage when using Firefox in private mode by default. Extension storage is reliable since it works in all contexts, though it may not be the most performant one. To speed-up loading of resources from extension storage, uBO will now make use of Cache API storage, which will mirror content of key assets saved to extension storage. Typically loading resources from Cache API is faster than loading the same resources from the extension storage. Only resources which must be loaded in memory as fast as possible will make use of the Cache API storage layered on top of the extension storage. Compiled filter lists and memory snapshot of filtering engines (aka "selfies") will be mirrored to the Cache API storage, since these must be loaded into memory as fast as possible, and reloading filter lists from their compiled counterpart is a common operation. This new design makes it now seamless to work in permanent private mode for Firefox-based browsers, since extension storage now always contains cache-related assets. Support for IndexedDB is removed for the time being, except to support migration of cached assets the first time uBO runs with the new cache storage design. In order to easily support all choices of storage, a new serializer has been introduced, which is capable of serializing/deserializing structure-cloneable data to/from a JS string. Because of this new serializer, JS data structures can be stored directly from their native representation, and deserialized directly to their native representation from uBO's point of view, since the serialization occurs (if needed) only at the storage interface level. This new serializer simplifies many code paths where data structures such as Set, Map, TypedArray, RegExp, etc. had to be converted in a disparate manner to be able to persist them to extension storage. The new serializer supports workers and LZ4 compression. These can be configured through advanced settings. With this new layered design, it's possible to introduce more storage layers if measured as beneficial (i.e. maybe browser.storage.session) References: - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local - https://developer.mozilla.org/en-US/docs/Web/API/Cache - https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
2024-02-26 22:50:11 +01:00
let selfieIsInvalid = false;
2015-02-24 19:48:03 +01:00
if ( fetched.compiledMagic !== µb.systemSettings.compiledMagic ) {
µb.compiledFormatChanged = true;
Redesign cache storage In uBO, the "cache storage" is used to save resources which can be safely discarded, though at the cost of having to fetch or recompute them again. Extension storage (browser.storage.local) is now always used as cache storage backend. This has always been the default for Chromium-based browsers. For Firefox-based browsers, IndexedDB was used as backend for cache storage, with fallback to extension storage when using Firefox in private mode by default. Extension storage is reliable since it works in all contexts, though it may not be the most performant one. To speed-up loading of resources from extension storage, uBO will now make use of Cache API storage, which will mirror content of key assets saved to extension storage. Typically loading resources from Cache API is faster than loading the same resources from the extension storage. Only resources which must be loaded in memory as fast as possible will make use of the Cache API storage layered on top of the extension storage. Compiled filter lists and memory snapshot of filtering engines (aka "selfies") will be mirrored to the Cache API storage, since these must be loaded into memory as fast as possible, and reloading filter lists from their compiled counterpart is a common operation. This new design makes it now seamless to work in permanent private mode for Firefox-based browsers, since extension storage now always contains cache-related assets. Support for IndexedDB is removed for the time being, except to support migration of cached assets the first time uBO runs with the new cache storage design. In order to easily support all choices of storage, a new serializer has been introduced, which is capable of serializing/deserializing structure-cloneable data to/from a JS string. Because of this new serializer, JS data structures can be stored directly from their native representation, and deserialized directly to their native representation from uBO's point of view, since the serialization occurs (if needed) only at the storage interface level. This new serializer simplifies many code paths where data structures such as Set, Map, TypedArray, RegExp, etc. had to be converted in a disparate manner to be able to persist them to extension storage. The new serializer supports workers and LZ4 compression. These can be configured through advanced settings. With this new layered design, it's possible to introduce more storage layers if measured as beneficial (i.e. maybe browser.storage.session) References: - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local - https://developer.mozilla.org/en-US/docs/Web/API/Cache - https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
2024-02-26 22:50:11 +01:00
selfieIsInvalid = true;
ubolog(`Serialized format of static filter lists changed`);
2015-02-24 00:31:29 +01:00
}
2015-02-24 19:48:03 +01:00
if ( fetched.selfieMagic !== µb.systemSettings.selfieMagic ) {
Redesign cache storage In uBO, the "cache storage" is used to save resources which can be safely discarded, though at the cost of having to fetch or recompute them again. Extension storage (browser.storage.local) is now always used as cache storage backend. This has always been the default for Chromium-based browsers. For Firefox-based browsers, IndexedDB was used as backend for cache storage, with fallback to extension storage when using Firefox in private mode by default. Extension storage is reliable since it works in all contexts, though it may not be the most performant one. To speed-up loading of resources from extension storage, uBO will now make use of Cache API storage, which will mirror content of key assets saved to extension storage. Typically loading resources from Cache API is faster than loading the same resources from the extension storage. Only resources which must be loaded in memory as fast as possible will make use of the Cache API storage layered on top of the extension storage. Compiled filter lists and memory snapshot of filtering engines (aka "selfies") will be mirrored to the Cache API storage, since these must be loaded into memory as fast as possible, and reloading filter lists from their compiled counterpart is a common operation. This new design makes it now seamless to work in permanent private mode for Firefox-based browsers, since extension storage now always contains cache-related assets. Support for IndexedDB is removed for the time being, except to support migration of cached assets the first time uBO runs with the new cache storage design. In order to easily support all choices of storage, a new serializer has been introduced, which is capable of serializing/deserializing structure-cloneable data to/from a JS string. Because of this new serializer, JS data structures can be stored directly from their native representation, and deserialized directly to their native representation from uBO's point of view, since the serialization occurs (if needed) only at the storage interface level. This new serializer simplifies many code paths where data structures such as Set, Map, TypedArray, RegExp, etc. had to be converted in a disparate manner to be able to persist them to extension storage. The new serializer supports workers and LZ4 compression. These can be configured through advanced settings. With this new layered design, it's possible to introduce more storage layers if measured as beneficial (i.e. maybe browser.storage.session) References: - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local - https://developer.mozilla.org/en-US/docs/Web/API/Cache - https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
2024-02-26 22:50:11 +01:00
selfieIsInvalid = true;
ubolog(`Serialized format of selfie changed`);
2015-02-24 00:31:29 +01:00
}
Redesign cache storage In uBO, the "cache storage" is used to save resources which can be safely discarded, though at the cost of having to fetch or recompute them again. Extension storage (browser.storage.local) is now always used as cache storage backend. This has always been the default for Chromium-based browsers. For Firefox-based browsers, IndexedDB was used as backend for cache storage, with fallback to extension storage when using Firefox in private mode by default. Extension storage is reliable since it works in all contexts, though it may not be the most performant one. To speed-up loading of resources from extension storage, uBO will now make use of Cache API storage, which will mirror content of key assets saved to extension storage. Typically loading resources from Cache API is faster than loading the same resources from the extension storage. Only resources which must be loaded in memory as fast as possible will make use of the Cache API storage layered on top of the extension storage. Compiled filter lists and memory snapshot of filtering engines (aka "selfies") will be mirrored to the Cache API storage, since these must be loaded into memory as fast as possible, and reloading filter lists from their compiled counterpart is a common operation. This new design makes it now seamless to work in permanent private mode for Firefox-based browsers, since extension storage now always contains cache-related assets. Support for IndexedDB is removed for the time being, except to support migration of cached assets the first time uBO runs with the new cache storage design. In order to easily support all choices of storage, a new serializer has been introduced, which is capable of serializing/deserializing structure-cloneable data to/from a JS string. Because of this new serializer, JS data structures can be stored directly from their native representation, and deserialized directly to their native representation from uBO's point of view, since the serialization occurs (if needed) only at the storage interface level. This new serializer simplifies many code paths where data structures such as Set, Map, TypedArray, RegExp, etc. had to be converted in a disparate manner to be able to persist them to extension storage. The new serializer supports workers and LZ4 compression. These can be configured through advanced settings. With this new layered design, it's possible to introduce more storage layers if measured as beneficial (i.e. maybe browser.storage.session) References: - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local - https://developer.mozilla.org/en-US/docs/Web/API/Cache - https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
2024-02-26 22:50:11 +01:00
if ( selfieIsInvalid === false ) { return; }
µb.selfieManager.destroy({ janitor: true });
cacheStorage.set(µb.systemSettings);
2015-02-24 19:48:03 +01:00
};
/******************************************************************************/
const onHiddenSettingsReady = async ( ) => {
// Maybe customize webext flavor
if ( µb.hiddenSettings.modifyWebextFlavor !== 'unset' ) {
const tokens = µb.hiddenSettings.modifyWebextFlavor.split(/\s+/);
for ( const token of tokens ) {
switch ( token[0] ) {
case '+':
vAPI.webextFlavor.soup.add(token.slice(1));
break;
case '-':
vAPI.webextFlavor.soup.delete(token.slice(1));
break;
default:
vAPI.webextFlavor.soup.add(token);
break;
}
}
ubolog(`Override default webext flavor with ${tokens}`);
}
// Maybe disable WebAssembly
if ( vAPI.canWASM && µb.hiddenSettings.disableWebAssembly !== true ) {
const wasmModuleFetcher = function(path) {
return fetch(`${path}.wasm`, { mode: 'same-origin' }).then(
WebAssembly.compileStreaming
).catch(reason => {
ubolog(reason);
});
};
staticNetFilteringEngine.enableWASM(wasmModuleFetcher, './js/wasm/').then(result => {
if ( result !== true ) { return; }
ubolog(`WASM modules ready ${Date.now()-vAPI.T0} ms after launch`);
});
}
};
/******************************************************************************/
const onFirstFetchReady = (fetched, adminExtra) => {
// https://github.com/uBlockOrigin/uBlock-issues/issues/507
// Firefox-specific: somehow `fetched` is undefined under certain
// circumstances even though we asked to load with default values.
if ( fetched instanceof Object === false ) {
fetched = createDefaultProps();
}
2015-02-24 19:48:03 +01:00
// Order is important -- do not change:
2015-03-07 05:36:09 +01:00
fromFetch(µb.localSettings, fetched);
fromFetch(µb.restoreBackupSettings, fetched);
permanentFirewall.fromString(fetched.dynamicFilteringString);
sessionFirewall.assign(permanentFirewall);
permanentURLFiltering.fromString(fetched.urlFilteringString);
sessionURLFiltering.assign(permanentURLFiltering);
permanentSwitches.fromString(fetched.hostnameSwitchesString);
sessionSwitches.assign(permanentSwitches);
onNetWhitelistReady(fetched.netWhitelist, adminExtra);
2015-02-24 19:48:03 +01:00
};
/******************************************************************************/
const toFetch = (from, fetched) => {
Refactor selfie generation into a more flexible persistence mechanism The motivation is to address the higher peak memory usage at launch time with 3rd-gen HNTrie when a selfie was present. The selfie generation prior to this change was to collect all filtering data into a single data structure, and then to serialize that whole structure at once into storage (using JSON.stringify). However, HNTrie serialization requires that a large UintArray32 be converted into a plain JS array, which itslef would be indirectly converted into a JSON string. This was the main reason why peak memory usage would be higher at launch from selfie, since the JSON string would need to be wholly unserialized into JS objects, which themselves would need to be converted into more specialized data structures (like that Uint32Array one). The solution to lower peak memory usage at launch is to refactor selfie generation to allow a more piecemeal approach: each filtering component is given the ability to serialize itself rather than to be forced to be embedded in the master selfie. With this approach, the HNTrie buffer can now serialize to its own storage by converting the buffer data directly into a string which can be directly sent to storage. This avoiding expensive intermediate steps such as converting into a JS array and then to a JSON string. As part of the refactoring, there was also opportunistic code upgrade to ES6 and Promise (eventually all of uBO's code will be proper ES6). Additionally, the polyfill to bring getBytesInUse() to Firefox has been revisited to replace the rather expensive previous implementation with an implementation with virtually no overhead.
2019-02-14 19:33:55 +01:00
for ( const k in from ) {
if ( from.hasOwnProperty(k) === false ) { continue; }
2015-02-24 19:48:03 +01:00
fetched[k] = from[k];
}
};
const fromFetch = (to, fetched) => {
Refactor selfie generation into a more flexible persistence mechanism The motivation is to address the higher peak memory usage at launch time with 3rd-gen HNTrie when a selfie was present. The selfie generation prior to this change was to collect all filtering data into a single data structure, and then to serialize that whole structure at once into storage (using JSON.stringify). However, HNTrie serialization requires that a large UintArray32 be converted into a plain JS array, which itslef would be indirectly converted into a JSON string. This was the main reason why peak memory usage would be higher at launch from selfie, since the JSON string would need to be wholly unserialized into JS objects, which themselves would need to be converted into more specialized data structures (like that Uint32Array one). The solution to lower peak memory usage at launch is to refactor selfie generation to allow a more piecemeal approach: each filtering component is given the ability to serialize itself rather than to be forced to be embedded in the master selfie. With this approach, the HNTrie buffer can now serialize to its own storage by converting the buffer data directly into a string which can be directly sent to storage. This avoiding expensive intermediate steps such as converting into a JS array and then to a JSON string. As part of the refactoring, there was also opportunistic code upgrade to ES6 and Promise (eventually all of uBO's code will be proper ES6). Additionally, the polyfill to bring getBytesInUse() to Firefox has been revisited to replace the rather expensive previous implementation with an implementation with virtually no overhead.
2019-02-14 19:33:55 +01:00
for ( const k in to ) {
if ( to.hasOwnProperty(k) === false ) { continue; }
if ( fetched.hasOwnProperty(k) === false ) { continue; }
2015-02-24 19:48:03 +01:00
to[k] = fetched[k];
}
2015-02-24 00:31:29 +01:00
};
const createDefaultProps = ( ) => {
Refactor selfie generation into a more flexible persistence mechanism The motivation is to address the higher peak memory usage at launch time with 3rd-gen HNTrie when a selfie was present. The selfie generation prior to this change was to collect all filtering data into a single data structure, and then to serialize that whole structure at once into storage (using JSON.stringify). However, HNTrie serialization requires that a large UintArray32 be converted into a plain JS array, which itslef would be indirectly converted into a JSON string. This was the main reason why peak memory usage would be higher at launch from selfie, since the JSON string would need to be wholly unserialized into JS objects, which themselves would need to be converted into more specialized data structures (like that Uint32Array one). The solution to lower peak memory usage at launch is to refactor selfie generation to allow a more piecemeal approach: each filtering component is given the ability to serialize itself rather than to be forced to be embedded in the master selfie. With this approach, the HNTrie buffer can now serialize to its own storage by converting the buffer data directly into a string which can be directly sent to storage. This avoiding expensive intermediate steps such as converting into a JS array and then to a JSON string. As part of the refactoring, there was also opportunistic code upgrade to ES6 and Promise (eventually all of uBO's code will be proper ES6). Additionally, the polyfill to bring getBytesInUse() to Firefox has been revisited to replace the rather expensive previous implementation with an implementation with virtually no overhead.
2019-02-14 19:33:55 +01:00
const fetchableProps = {
'dynamicFilteringString': µb.dynamicFilteringDefault.join('\n'),
2016-01-03 19:58:25 +01:00
'urlFilteringString': '',
'hostnameSwitchesString': µb.hostnameSwitchesDefault.join('\n'),
2016-01-03 19:58:25 +01:00
'lastRestoreFile': '',
'lastRestoreTime': 0,
'lastBackupFile': '',
'lastBackupTime': 0,
'netWhitelist': µb.netWhitelistDefault,
2016-01-03 19:58:25 +01:00
'version': '0.0.0.0'
2015-10-21 17:53:03 +02:00
};
2016-01-03 19:58:25 +01:00
toFetch(µb.localSettings, fetchableProps);
toFetch(µb.restoreBackupSettings, fetchableProps);
return fetchableProps;
2016-01-03 19:58:25 +01:00
};
2017-01-26 16:17:38 +01:00
/******************************************************************************/
(async ( ) => {
// >>>>> start of async/await scope
try {
2023-03-18 19:37:49 +01:00
ubolog(`Start sequence of loading storage-based data ${Date.now()-vAPI.T0} ms after launch`);
// https://github.com/gorhill/uBlock/issues/531
await µb.restoreAdminSettings();
ubolog(`Admin settings ready ${Date.now()-vAPI.T0} ms after launch`);
await µb.loadHiddenSettings();
await onHiddenSettingsReady();
ubolog(`Hidden settings ready ${Date.now()-vAPI.T0} ms after launch`);
2016-01-03 19:58:25 +01:00
const adminExtra = await vAPI.adminStorage.get('toAdd');
ubolog(`Extra admin settings ready ${Date.now()-vAPI.T0} ms after launch`);
// Maybe override default cache storage
µb.supportStats.cacheBackend = await cacheStorage.select(
µb.hiddenSettings.cacheStorageAPI
);
ubolog(`Backend storage for cache will be ${µb.supportStats.cacheBackend}`);
Redesign cache storage In uBO, the "cache storage" is used to save resources which can be safely discarded, though at the cost of having to fetch or recompute them again. Extension storage (browser.storage.local) is now always used as cache storage backend. This has always been the default for Chromium-based browsers. For Firefox-based browsers, IndexedDB was used as backend for cache storage, with fallback to extension storage when using Firefox in private mode by default. Extension storage is reliable since it works in all contexts, though it may not be the most performant one. To speed-up loading of resources from extension storage, uBO will now make use of Cache API storage, which will mirror content of key assets saved to extension storage. Typically loading resources from Cache API is faster than loading the same resources from the extension storage. Only resources which must be loaded in memory as fast as possible will make use of the Cache API storage layered on top of the extension storage. Compiled filter lists and memory snapshot of filtering engines (aka "selfies") will be mirrored to the Cache API storage, since these must be loaded into memory as fast as possible, and reloading filter lists from their compiled counterpart is a common operation. This new design makes it now seamless to work in permanent private mode for Firefox-based browsers, since extension storage now always contains cache-related assets. Support for IndexedDB is removed for the time being, except to support migration of cached assets the first time uBO runs with the new cache storage design. In order to easily support all choices of storage, a new serializer has been introduced, which is capable of serializing/deserializing structure-cloneable data to/from a JS string. Because of this new serializer, JS data structures can be stored directly from their native representation, and deserialized directly to their native representation from uBO's point of view, since the serialization occurs (if needed) only at the storage interface level. This new serializer simplifies many code paths where data structures such as Set, Map, TypedArray, RegExp, etc. had to be converted in a disparate manner to be able to persist them to extension storage. The new serializer supports workers and LZ4 compression. These can be configured through advanced settings. With this new layered design, it's possible to introduce more storage layers if measured as beneficial (i.e. maybe browser.storage.session) References: - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local - https://developer.mozilla.org/en-US/docs/Web/API/Cache - https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
2024-02-26 22:50:11 +01:00
const lastVersion = await vAPI.storage.get(createDefaultProps()).then(async fetched => {
ubolog(`Version ready ${Date.now()-vAPI.T0} ms after launch`);
await onVersionReady(fetched.version);
return fetched;
}).then(fetched => {
ubolog(`First fetch ready ${Date.now()-vAPI.T0} ms after launch`);
onFirstFetchReady(fetched, adminExtra);
return fetched.version;
});
await Promise.all([
µb.loadSelectedFilterLists().then(( ) => {
ubolog(`List selection ready ${Date.now()-vAPI.T0} ms after launch`);
}),
µb.loadUserSettings().then(fetched => {
ubolog(`User settings ready ${Date.now()-vAPI.T0} ms after launch`);
onUserSettingsReady(fetched);
}),
µb.loadPublicSuffixList().then(( ) => {
ubolog(`PSL ready ${Date.now()-vAPI.T0} ms after launch`);
}),
Redesign cache storage In uBO, the "cache storage" is used to save resources which can be safely discarded, though at the cost of having to fetch or recompute them again. Extension storage (browser.storage.local) is now always used as cache storage backend. This has always been the default for Chromium-based browsers. For Firefox-based browsers, IndexedDB was used as backend for cache storage, with fallback to extension storage when using Firefox in private mode by default. Extension storage is reliable since it works in all contexts, though it may not be the most performant one. To speed-up loading of resources from extension storage, uBO will now make use of Cache API storage, which will mirror content of key assets saved to extension storage. Typically loading resources from Cache API is faster than loading the same resources from the extension storage. Only resources which must be loaded in memory as fast as possible will make use of the Cache API storage layered on top of the extension storage. Compiled filter lists and memory snapshot of filtering engines (aka "selfies") will be mirrored to the Cache API storage, since these must be loaded into memory as fast as possible, and reloading filter lists from their compiled counterpart is a common operation. This new design makes it now seamless to work in permanent private mode for Firefox-based browsers, since extension storage now always contains cache-related assets. Support for IndexedDB is removed for the time being, except to support migration of cached assets the first time uBO runs with the new cache storage design. In order to easily support all choices of storage, a new serializer has been introduced, which is capable of serializing/deserializing structure-cloneable data to/from a JS string. Because of this new serializer, JS data structures can be stored directly from their native representation, and deserialized directly to their native representation from uBO's point of view, since the serialization occurs (if needed) only at the storage interface level. This new serializer simplifies many code paths where data structures such as Set, Map, TypedArray, RegExp, etc. had to be converted in a disparate manner to be able to persist them to extension storage. The new serializer supports workers and LZ4 compression. These can be configured through advanced settings. With this new layered design, it's possible to introduce more storage layers if measured as beneficial (i.e. maybe browser.storage.session) References: - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local - https://developer.mozilla.org/en-US/docs/Web/API/Cache - https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm
2024-02-26 22:50:11 +01:00
cacheStorage.get({ compiledMagic: 0, selfieMagic: 0 }).then(bin => {
ubolog(`Cache magic numbers ready ${Date.now()-vAPI.T0} ms after launch`);
onCacheSettingsReady(bin);
}),
]);
// https://github.com/uBlockOrigin/uBlock-issues/issues/1547
if ( lastVersion === '0.0.0.0' && vAPI.webextFlavor.soup.has('chromium') ) {
vAPI.app.restart();
return;
}
} catch (ex) {
console.trace(ex);
}
// Prime the filtering engines before first use.
staticNetFilteringEngine.prime();
// https://github.com/uBlockOrigin/uBlock-issues/issues/817#issuecomment-565730122
// Still try to load filter lists regardless of whether a serious error
// occurred in the previous initialization steps.
let selfieIsValid = false;
try {
selfieIsValid = await µb.selfieManager.load();
if ( selfieIsValid === true ) {
ubolog(`Loaded filtering engine from selfie ${Date.now()-vAPI.T0} ms after launch`);
}
} catch (ex) {
console.trace(ex);
}
if ( selfieIsValid !== true ) {
try {
await µb.loadFilterLists();
ubolog(`Filter lists ready ${Date.now()-vAPI.T0} ms after launch`);
} catch (ex) {
console.trace(ex);
}
}
2016-01-03 19:58:25 +01:00
// Flush memory cache -- unsure whether the browser does this internally
// when loading a new extension.
filteringBehaviorChanged();
// Final initialization steps after all needed assets are in memory.
// https://github.com/uBlockOrigin/uBlock-issues/issues/974
// This can be used to defer filtering decision-making.
µb.readyToFilter = true;
// Initialize internal state with maybe already existing tabs.
await initializeTabs();
// Start network observers.
webRequest.start();
// Ensure that the resources allocated for decompression purpose (likely
// large buffers) are garbage-collectable immediately after launch.
// Otherwise I have observed that it may take quite a while before the
// garbage collection of these resources kicks in. Relinquishing as soon
// as possible ensure minimal memory usage baseline.
lz4Codec.relinquish();
// https://github.com/chrisaljoudi/uBlock/issues/184
// Check for updates not too far in the future.
io.addObserver(µb.assetObserver.bind(µb));
µb.scheduleAssetUpdater({
updateDelay: µb.userSettings.autoUpdate
? µb.hiddenSettings.autoUpdateDelayAfterLaunch * 1000
: 0
});
// Force an update of the context menu according to the currently
// active tab.
contextMenu.update();
// https://github.com/uBlockOrigin/uBlock-issues/issues/717
// Prevent the extension from being restarted mid-session.
browser.runtime.onUpdateAvailable.addListener(details => {
const toInt = vAPI.app.intFromVersion;
if (
µb.hiddenSettings.extensionUpdateForceReload === true ||
toInt(details.version) <= toInt(vAPI.app.version)
) {
vAPI.app.restart();
}
});
µb.supportStats.allReadyAfter = `${Date.now() - vAPI.T0} ms`;
if ( selfieIsValid ) {
µb.supportStats.allReadyAfter += ' (selfie)';
}
ubolog(`All ready ${µb.supportStats.allReadyAfter} after launch`);
2015-03-11 23:26:00 +01:00
µb.isReadyResolve();
// Process alarm queue
while ( µb.alarmQueue.length !== 0 ) {
const what = µb.alarmQueue.shift();
ubolog(`Processing alarm event from suspended state: '${what}'`);
switch ( what ) {
case 'createSelfie':
µb.selfieManager.create();
break;
}
}
// <<<<< end of async/await scope
})();