Add support for Twitter tips

[emerick]

Fixes brave/brave-browser#4346
Fixes brave/brave-browser#4393

Adds support for Twitter tips, as described in https://docs.google.com/document/d/1OlRWQ1Ksqyt6XT5N0_k503sRP-7clEthDFG1BXeZI5E

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 && npm run test-security) on
  • 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:

Note: You can create a verified Twitter publisher by visiting this special link and following the Twitter flow:

https://publishers-staging.basicattentiontoken.org/publishers/home?twitter=true

Enabling/disabling the Brave Tip icon

• Launch Brave on a new profile and keep Brave Rewards disabled
• Visit twitter.com.
• Ensure that the BAT tip icon doesn't appear in the action section of any tweets.
• Enable Brave Rewards.
• Ensure that Brave tip icons dynamically appear in Twitter feed within a few seconds.
• Visit brave://rewards and uncheck "Twitter" in Tips Settings
• Ensure that the Brave tip icons dynamically disappear from the Twitter feed within a few seconds.
• Reenable Brave Rewards and the tip icons should appear again.
• Scroll far enough into the Twitter feed that new tweets dynamically load (infinite scroll) and ensure that the tip icons appear in the newly loaded tweets.
• Click on a tweet and ensure that the tip icons load in the new overlay window that appears.

Tipping a Twitter user

• Click on a Tip icon for a Twitter user and ensure that the tip overlay dialog shows the appropriate "compliment" message, the relevant tweet/date, and the full name and screen name of the Twitter user. The dialog should respect all of the privacy standards for verified/unverified users as with the standard Tip dialog, so please test with both verified and unverified Twitter users.
• The tip dialog should respect custom tip amounts, if any are set.
• Upon sending the tip, you should receive a thank you message and an offer to tweet your tip.
• Clicking the "Tweet Now" button should populate a new tab with a message and the relevant quoted tweet.
• The quoted tweet shouldn't contain any clickable links.
• Posting the tweet should work as expected, but please delete the tweet afterward for now.

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

[petemill]

I reviewed the button-injection methodology and left some feedback. This is great!

[petemill]

I suggest we don't add a css file to the content_scripts since, unlike JS, I believe this is added to the global document styles. Instead, especially since these styles are minimal, perhaps we add them via JS, and ideally within a shadow DOM so that nothing is affected by the document's stylesheet.

[emerick]

Great point, I didn't realize that. Will fix, thank you.

[petemill]

Again, suggest we expose as little as possible to the site. Here, we can inline an SVG. Or, if it must be PNG (not ideal since not scalable), then that can be inlined via data: URI.

[emerick]

SVG should work I think, I'll investigate.

[petemill]

Right now I believe this method of creating DOM elements has the following issues that were brought up in an older security discussion:

• The site can detect that the user is a Brave Rewards user via detecting the element
• The site can intercept the click and do something malicious
• The site's styles can unintentionally / intentionally interfere with the button.

These issues can be at least minimized by at least creating a single element, and then putting all the button content inside that element's shadow DOM.

And then, we could explore not having to add an element at all, but instead adding the button to the parent's closed shadow DOM. This is what I did on my prototype for the popup.

Let me know what you think @emerick

[emerick]

Really good point, will get that in there!

[emerick]

@petemill Do you happen to know: is there a clever way to access a CSS class defined in the parent document from the shadow DOM? The issue I'm running into is that we reference a handful of CSS classes defined in the Twitter stylesheet, but the shadow DOM doesn't have access to those styles. I'm reluctant to copy those underlying styles directly into the shadow DOM as then it becomes kind of brittle (e.g., if/when Twitter tweaks those styles).

[petemill]

No, I guess that's the point of the shadow DOM - that the document styles cannot affect the shadow elements. So it's a trade-off between wanting to affect the styles intentionally and not wanting unintentional or malicious styles. Perhaps someone like @diracdeltas could weight in on the priority.

However, I would add that using the css class names could be just as brittle, since these could change anytime. One way to somewhat get around that (again not using shadow DOM) would be to find an existing button's node that is a sibling of our 'tip' button, and call .cloneNode() on it, then add our own (inline) styles to override.

Are there many / any native document styles that we need to inherit anyway, since AFAIK our button is simply our icon?

[emerick]

Right, I see what you're saying (and you make a good point about the class names). I think you're right that we don't end up needing very many of the inherited styles, just some text properties for the "Tip" label and sizing properties most likely. Probably not too much harm including them in the shadow DOM if that's the case. I'll experiment with that, thanks again!

[diracdeltas]

++ for encapsulating our injected element in a shadow DOM

[emerick]

Added to shadow DOM.