Proposes alternative tipping logic

[jonathansampson]

Addresses #100

The goal here is to retrieve from the front-end data that was previously retrieved via the API.

It is important to note that this script must be ran in the main world, and not in an isolated world. If it is ran in an isolated world it will not have access to React properties.

Here is an example of the input/output:

[emerick]

@jonathansampson Seems like there are still some build errors based on the CI above - sorry if I reviewed before it was ready! Thanks for undertaking this, BTW.

[Miyayes]

Addresses brave/brave-browser#32615

[jonathansampson]

@emerick Yeah, apologies. I just pushed to address some/all of those build issues.

[zenparsing]

This is awesome - thanks @jonathansampson!

[zenparsing]

nit: 2-spaces indentation.

[jonathansampson]

On a related note, how up-to-date are our linting rules in the project itself? Do we enforce single quotes, two-space tabs, and more? I wasn't having much success with --fix.

[jonathansampson]

@zenparsing Do you know if these scripts are executing in the main world, so as to have access to the React state to begin with?

[emerick]

@zenparsing Do you know if these scripts are executing in the main world, so as to have access to the React state to begin with?

I think they run in an isolated world actually, because they're just dynamically-generated content scripts and I don't see them setting the world key when building their manifest here:

https://github.com/brave/brave-core/blob/master/components/greaselion/browser/greaselion_service_impl.cc#L125

We would probably have to test this out to be 100% sure, though. BTW, I use the following aliases to build and "deploy" Greaselion locally when testing. I thought you might find them helpful (they're geared towards Windows directories at the moment):

alias bldgrease='npm run --prefix "${GREASELIONDIR}" build -- --mode=development && npm run --prefix "${GREASELIONDIR}" lint && npm run --prefix "${GREASELIONDIR}" test'
alias deploygrease='( cd "${GREASELIONDIR}/dist"; /bin/cp -R * "${PROFILEDIR}/${GREASELIONEXTENSIONID}"/[0-9]*.[0-9]*.[0-9]*/1 )'

[zenparsing]

@jonathansampson @emerick We should definitely test to make sure we can get to the React state from the script, and that everything works as expected. I have some other commitments at the moment, but I'll try to do some testing over the next couple of days.

[emerick]

Hi @jonathansampson, I tested this out today locally.

One thing we should probably do in this PR is revert the following commit which temporarily disabled Twitter-based inline tipping: f0079ae

I did that locally but it seems like the React store initialization is failing. I saw the following messages:

Greaselion script loaded: twitterBase.ts
twitterInlineTipping.bundle.js:1033 Greaselion script loaded: twitterInlineTipping.ts
twitterInlineTipping.bundle.js:550 Failed to fetch tweet details for 1707565081750290910: XStore initialization failed
(anonymous) @ twitterInlineTipping.bundle.js:550
Promise.catch (async)
getMediaMetaData @ twitterInlineTipping.bundle.js:549
tipButton.onclick @ twitterInlineTipping.bundle.js:625
twitterInlineTipping.bundle.js:632 Failed to fetch tweet metadata for [object HTMLElement]: Error: XStore initialization failed
    at getXState (twitterInlineTipping.bundle.js:349:11)
    at getEntities (twitterInlineTipping.bundle.js:351:27)
    at Module.getTweetDetails (twitterInlineTipping.bundle.js:357:22)
    at getMediaMetaData (twitterInlineTipping.bundle.js:532:46)
    at tipButton.onclick (twitterInlineTipping.bundle.js:625:13)

Just for testing purposes, I added the following line to the Greaselion service but it didn't appear to have any effect so I'm not sure if there's more to running a content script in the main world:

  content_script.world =
      extensions::api::extension_types::ExecutionWorld::kMain;

If we do find a way to run this content script in the main world, we'd have to run that approach by our security folks of course. I'm not sure if this would be a non-starter for them, but it might make sense to start having that conversation now just in case.

If there's something you'd like me to inspect while running in this mode, let me know!

[jonathansampson]

I had a productive call with @emerick this morning to take a closer look at the extension. From our cursory review, it seems clear that the extension logic works. That said, we identified a couple obstacles.

MV3 Route

First, we currently register grease lion scripts via manifest v2. In order to easily execute the updated script in the main world, we would need to register it with v3 (which adds support for a world property on the content_scripts manifest object. This alone is not sufficient, as hopping from v2 to v3 requires other changes. For example, we will no longer have access to chrome.runtime.sendMessage from the script, meaning we'd need to make changes to our messaging approach (likely for this script alone; all other scripts could continue to use the established method).

There are a couple other migration-related changes that would need to be made (e.g., around detection of an incognito window context) as well. As such, before this work can proceed we need to do the following:

• Evaluate further if we wish to deploy this logic under manifest v3 (input from security team needed)
• Modify our content script registration logic to handle this script differently from all others
• Update the existing script to apply all required mv2-to-mv3 changes (e.g., incognito detection, etc.)

MV2 Route

It is also possible to proceed with mv2, but we would need to create a background script for this extension, and register the content script(s) via chrome.scripting.registerContentScripts so as to specify the execution world (i.e., main vs isolated).

This approach would also require a change to our manifest-creation process, specifying a background property for the X (i.e., Twitter) script, and no other. Security should also still be consulted since this approach, while not deviating from MV2, does still introduce main-world script execution. Additionally, we would likely still need to make changes to the messaging approach.

• Evaluate further if we're comfortable with main-world script execution (needs Security team input)
• Modify the script as needed to accommodate API restrictions to main-world scripts (e.g., around messaging)

[diracdeltas]

Please open a security review for this.

[Miyayes]

No longer relevant as we've removed the inline Tip buttons feature entirely.