Optimize multiple initializations of content_cosmetics.bundle.js during frame load

[atuchin-m]

Description

The problem is content_cosmetics.bundle.js sometimes is injected and initialized twice during each main frame load.
(see the picture in attachment)

The reason is that webpack bundle mechanisms aren't designed for multiple injections.
In addition, some caching mechanisms don't work correctly (for example _parseDomainCache).

The bundle should be injected once, with no double execution/code-optimization during frame load.
The native code should call some exported functions.

Steps to Reproduce

1. Visit a very simple HTML page like https://example.com
2. Open Developer Tools: Performance
3. Click record page load time.
4. Look for large "Evaluate Script" tasks after ParseHTML task.

Actual result:

See two large tasks spawned by injecting content_cosmetics.bundle.js (better to use built from source version to see the stack details). The script was injected from native code: https://github.com/brave/brave-core/blob/713692eb65af2adf39c9375d5c6f87f5afd830a6/components/cosmetic_filters/renderer/cosmetic_filters_js_handler.cc#L196-L198

Expected result:

Only one such task.

Reproduces how often:

Easily reproduced

[iefremov]

cc @antonok-edm @pes10k @SergeyZhukovsky

[antonok-edm]

@atuchin-m / @iefremov perhaps you can verify, but I believe this is fixed by brave/brave-core#9995:

[SergeyZhukovsky]

@atuchin-m the description of the issue is incorrect. The bundle isn't injected on every frame at all. We do that only in the main frame https://github.com/brave/brave-core/blob/master/components/cosmetic_filters/renderer/cosmetic_filters_js_handler.cc#L341
In most cases the injection happens only once and as I mentioned above on the main frame only.

[atuchin-m]

@pes10k
Agreed, especially after removing extension implementation (which was not limited to main frames).
I've corrected the description: added sometimes and during each main frame load

[stephendonner]

Verified PASSED using

Brave	1.31.51 Chromium: 94.0.4606.50 (Official Build) nightly (x86_64)
Revision	0c1ac2c4842a4746c27c937c1a0453f98da1a972-refs/branch-heads/4606@{#1049}
OS	macOS Version 11.6 (Build 20G165)

Steps:

1. clean profile
2. launched Brave
3. opened Developer Tools' Performance tab
4. loaded https://example.com
5. clicked on the Record icon
6. reloaded the page
7. clicked on the Stop icon
8. compared beta to nightly

Confirmed:

1. The main process time went from 343ms -> 12ms, with a huge chunk of that reduction coming from Scripting (103ms -> 6ms).
2. Page load ranges went down, from:

beta: 3.68s - 4.02s

to

nightly: 2.46s - 2.47s

beta	nightly

---

Verified PASSED using

Brave	1.31.73 Chromium: 94.0.4606.71 (Official Build) beta (64-bit)
Revision	1d32b169326531e600d836bd395efc1b53d0f6ef-refs/branch-heads/4606@{#1256}
OS	Linux

Steps:

1. clean profile
2. launched Brave
3. opened Developer Tools' Performance tab
4. loaded https://example.com
5. clicked on the Record icon
6. reloaded the page
7. clicked on the Stop icon
8. compared release to beta

Confirmed:

We went from 201ms down to 27ms for the "main" Task

---

Verification passed on

Brave | 1.31.74 Chromium: 94.0.4606.71 (Official Build) beta (64-bit)
-- | --
Revision | 1d32b169326531e600d836bd395efc1b53d0f6ef-refs/branch-heads/4606@{#1256}
OS | Windows 10 Version 21H1 (Build 19043.1266)

Steps:

1. clean profile
2. launched Brave
3. opened Developer Tools' Performance tab
4. loaded https://example.com
5. clicked on the Record icon
6. reloaded the page
7. clicked on the Stop icon
8. compared release to beta

Confirmed:

We went from 45ms down to 17ms for the "main" Task

Release 1.30.x	Beta 1.31.x

[srirambv]

Verification passed on Oppo Reno 5 with Android 11 running 1.31.73 x64 build

• Verified load time went down fro 260 ms to 89 ms

1.30.87 Release	1.31.73 Beta