Updated brave extension to wait for css selector

[reaktivo]

Parent issue: brave/brave-browser#2410
Copying description from brave/brave-extension#94:

There's a performance issue when right-clicking on a Twitter timeline, this is due to the way Twitter builds it's elements (with dozens of css class names) which impacts the way the library unique-selector finds elements. This causes a few seconds delay every time anything on a Twitter timeline is clicked.

You can see a bit more details here: https://community.brave.com/t/right-click-hangs-on-mobile-twitter/43332/4

This PR rewrites brave extension's content.ts and background/events/cosmeticFilterEvents.ts so that the actual unique call only happens after the Context sub menu item is clicked.

FYI, I wasn't able to get this changes running locally, so I've wrote this PR blindly – I not 100% sure it's going to work. Any guidance on this would be appreciated.

Submitter Checklist:

• Submitted a ticket for my issue if one did not already exist.
• Used Github auto-closing keywords in the commit message.
• Added/updated tests for this change (for new code or code which already has tests).
• Verified that these changes build without errors on
  • Windows
  • macOS
  • Linux
• Verified that these changes pass automated tests (npm test brave_unit_tests && npm test brave_browser_tests) on (Ran npm run test-unit instead)
  • Windows
  • macOS
  • Linux
• Verified that all lint errors/warnings are resolved (npm run lint)
• Ran git rebase master (if needed).
• Ran git rebase -i to squash commits (if needed).
• Tagged reviewers and labelled the pull request as needed.
• Request a security/privacy review as needed.
• Add appropriate QA labels (QA/Yes or QA/No) to include the closed issue in milestone

Test Plan:

Reviewer Checklist:

• New files have MPL-2.0 license header.
• Request a security/privacy review as needed.
• Adequate test coverage exists to prevent regressions
• Verify test plan is specified in PR before merging to source

[reaktivo]

@cezaraugusto could you give this one a look?

[cezaraugusto]

hi @reaktivo thanks a lot for making this PR!

the cosmetic filter needs to be bound to the contextMenu; otherwise, it would appear at any interaction such as toggling shields on/off. for context this is what happened when I disabled shields:

since you mentioned that you did this blindly, I'd suggest you take a look at our build instructions at https://github.com/brave/brave-browser/wiki. In there you will see everything you need to set up Brave for development. once that is done, the heart of brave (brave-core -- this repo) is under /src/brave.

if you need help setting up Brave, feel free to hit me up on Twitter, same username @cezaraugusto.

[bsclifton]

@reaktivo did you need help with this? If you haven't already hit up @cezaraugusto, please do 😄 Or you can ask for help here. We'd love to help you get this across the finish line

[reaktivo]

@bsclifton I won't be able to continue to work on this, although I would still love to see this fixed. My machine literally didn't manage to get Brave to compile since I don't have enough disk space and I wasn't able to find a way of testing the extension without baking it into the full browser.

Hopefully somebody can take this PR forward or can advise on testing the extension without a full build.

[bsclifton]

Thanks for the patch, @reaktivo!

This was a tough one- I have a proposed fix using a similar technique to what you did here. It's available for review, if you'd like to check it out:
#2043

Closing this PR in favor of that solution