* big refator to ui element's own service
* move native to own file
* add native type
* fix in layer checker
* fix in layer checker
* fix whitespace
* fix another whitespace
* Update layersChecker.js
* build still not passing
* Update layersChecker.js
* update layerChecker using npm run compile
* try updating layer checker rules
* rename simple browser service
* another rename in app.ts
* re-add drag and drop URLs, do some fetching
* add fallback by using canvas'
i
* some cleanup
* more cleanup
* more cleanup
* better handling
* remove unused function
* add sessionDefault
* move to webextractorservice
* ensure data type
* now using shared process
* make sure to register shared process
* add more headers to help specify:
* fix comment
* add register singlton to pass test
* adress some comments
* add cancellation token, rename
* no more text/html, better if cases
* address more comments
* make token required
We don't want these extra windows to cause anything to go wrong, so we replace explicit calls of `getAllWindows` with a wrapper that excludes them.
@deepak1556 and I also went through all other static APIs on BrowserWindow and found none that would be problematic to these new offscreen windows.
* Initial cut of WebContentExtractorService & a fetch tool
I will likely move the tool into Copilot so it can take advantage of prompt-tsx and embeddings indexing... but this is the first cut to play around with it.
This leverages Chrome DevTools Protocol's `Accessibility.getFullAXTree` command in order to get a representation of a page while marking what is useful on the page and what is not. We take the output of the command and turn it into a string that the caller can easily consume. This transformer will get more sophisticated over time to make sure we keep content that's important, and ditch content that is not.
On the tool side of things... this implements a Confirmation flow that verifies if the urls being requested is a trusted domain. We are _rendering_ these urls (albiet, sandboxed without JS) so we want to make sure they're safe. If it's not trusted, they'll be asked to confirm.
* fix naming
- There's an mcpDiscoveryRegistry that allows components to register in
how they discover MCP servers.
- Config discovery is one of these. Figured out all the bits for a
standalone file config shebang. Duplication there that could be
cleaned up but it works.
- The others are remote and local filesystem discovery. I ended up
making another message channel for the main process/remote server to
get a couple environment variables we need since I didn't see anything
generic for this already(?)
