In a previous commit we added a "bs_" (standing for "Brave Shields")
to all the settings' names for consistency, even if only "ads", cookies"
and "javascript" needed to be changed to prevent collissions with other
types from upstream when registering the types.
However this is problematic and confusing, so let's only modify the
ones strictly needed, that is, "cookies" and "ads". For "javascript"
we can simply stop registering our own ContentSettingsType for that
since the one that's actually being used is upstream's.
As part of upstream bug 1134547[1], the ResourceIdentifier that Brave
Shields relied on so far has been completely removed[2], so we need to
adapt our code not to rely on it anymore so that we can keep building
Brave correctly on the latest dev channel release of Chromium 88.
This patch implements the first step to adapt Brave to this new
scenario, by moving into using Brave-specific values of the
ContentSettingsType enumeration instead of using the PLUGINS
type plus a ResourceIdentifier as we did before.
Note that this patch adds a "bs_" prefix to all the BraveShields
constants, to avoid collisions with the COOKIES and JAVASCRIPT
upstream content types. Added prefix to all constants for
consistency + update TS code.
Note that the goal of this change is simply to keep Brave building,
running and passing the tests so that we can continue working on the
rebase. Further work will be still needed in follow-up patches to
fully migrate the code base to a post-Flash world by changing those
bits that don't make sense anymore, and simplifying things as much
as possible.
[1] https://crbug.com/1134547
[2] https://crrev.com/c/2500161
Reverts the revert of the oringal implementation: "Merge pull request #4255 from brave/bsc-revert-cosmetic-filtering"
This reverts commit fcfe38a549, reversing
changes made to 950778a7a1.
Fixes some conflicts as a result of master getting flag features and uses updated adblock-rust-ffi version which provides a slightly different API than for the original implementation.
Fix https://github.com/brave/brave-browser/issues/5249
The previous method of wvh->SetWebUIProperty has issues in that the rvh does not always fire the 'ready' event, especially when navigating 'back'. Using DataSource is a more consistent chromium method for sending properties to the JS context. However, this is usually used for non-changing data. Whilst an UpdateDataSource function does exist, that kind of data is usually pulled from the JS via an explicit call to the C++ WebUI, so we may have to go down that route. The issue with the implementation in this commit is that a page may miss the 'updated' events that fire, for example due to have being navigated away and then back to the page.
- Creates JS -> C++ functions to get data for: Preferences, Stats and PrivateProperties (alternativeSearchEngine). loadTimeData is also not a great place for data which can change. Although a DataSource (i.e. strings.js and loadTimeData.data) can be updated, it is complicated and is not normal chromium pattern. Since this data is not required exactly at page creation (since it is not read via static HTML but via React in JS), then we can afford the time it takes to request this data via JS.
- Converting to a JS API required refactoring some of the app store / reducer initialization, including creating the concept of 'initial data' which is any data required to render the page. Since we need Preferences to know what to show, and we need Stats since they are shown on the initial page load, then those are contained within.
Includes some minor cleanup with regard to 'API' separation and definition.
- Fixes storage being loaded multiple times during redux init (the function is called with an empty state param 3 times, so the state was being loaded from storage 3 times).
- Only saves to local storage the state which we will be re-used.
close https://github.com/brave/brave-browser/issues/4953
Shields state needed across windows/tabs is not stored in localStorage API.
This follows the webUI convention for persistent state.
Goal is to provide a way to handle upcoming changes such as onboarding screen
and simple/advanced view setting.
Other state such as stats, resources blocked, and blocking preferences are still
handled by the back-end and are left untouched.
setup redux: minimal actions and store
redux: add support for qr code seed and sync words
add qr-image dep, remove qrcode.js
interface: setup UI handler for sync words and qr code image
deprecate api and html original drafts
fix jest warning about ts-jest transform
add sync reducers test
remove leftover qrcode import from html file
remove useless pageLoaded action
add support for sync reset
add support for toggling main device sync
add support for toggling bookmarks sync
Revert "remove useless pageLoaded action"
This reverts commit 384587931158549220392873e3b01d405068aa02.
add support for toggling saved site settings sync
add support for toggling browsing history sync
add support for devices table
add support for syncing from another device
add support for excluding devices
add sync actions test
add sync: mapStateToProps, mapDispatchToProps and dumb component tests
add sync reducers test file
setup brave-ui for the main interface
add disabled content interface
add `new to sync` modal interface
add enabled content interface
add reset sync interface
do not use arrow function for lifecycle methods
safeguard action handlers when payload is undefined
add sync a new device interface
add existing sync code interface
lint
Mario Sanchez Prada