🛁 🦆

Current status: this is blocked for now. I've refactored the snippet into something that the extension can reuse, but running into some limitations of both the extension APIs and parcel. Need some time to think through different options. Braindump of the current situation:

• chrome.js sets up the handler when a user clicks the extension icon
• executeScript switches from "extension" context to "page" context
• we must be in "page" context to analyze the DOM and write to the console
• we must be in "extension" context to render the extension's color bar
• in order to render the color bar, we need to exfiltrate info about the head from "page" to "extension" context
• in order to handle clicks on the color bar, we need to inject info about the selected element into the "page" context
• capo.js can only run in isolation, without any inputs or outputs
• alternatively (and the way it worked previously) we can run code in a function scoped to chrome.js
  • inputs can only be primitives, not things like entire functions
  • the modules must be inlined to the function, but the extension barfs on parcel's dynamic imports

The next thing I'll try is:

• invoke capo.js on extension icon click
• since we can't return state back to the "extension" context, save it in a global var in the "page" context
  • also set up a function that we can call later when handling color bar clicks
• after the file executes, invoke an inline function to go back into "page" context and extract the data
• render the color bar and set up click handlers
• on color bar click, invoke another inline function that calls the "page" function we set up earlier

It might be too tricky for the page's click handler to have enough closure context to reuse the same logElement functionality. Another option would be to do the exfiltration in reverse: invoke a lightweight function to save some global state in the "page" context, invoke capo.js which goes back into "page" context, but checks that global state before going through the logging routine again, pick up the serialized metadata about the clicked element, and log it. Similar to the FN_EXPORTS approach but using globals as the intermediary rather than function params.

These problems might also go away if I figure out a way for parcel to properly inline the dependencies and not do dynamic imports. Or find a new build tool.

Resolved the issue as described, except I learned executeScript is async when running a file, despite the await. To work around the buffer/storage race condition, I used chrome.storage.onChanged.addListener to print as soon as the storage object was updated.

Also gave the options page a nice makeover while I was there
(thanks @argyleink https://github.com/argyleink/open-props!)