Due to how we detect content, being no category, not having a chrome URL, and having a http:// or file:// protocol, when running locally, using a chrome JS (no category) in gecko, coming from file:// where my gecko-dev checkout lives, this passes the tests. See attachment

Check out http://todomvc.com/examples/react/#/, as there's a lot of nsAutoComplete stuff.

I guess new pseudo stack entries were added without a category :/ We need to ask reviewers to r- such patches.

Oh, now I see the screenshot in more detail and that's not a psentry. I saw nsAutoComplete and immediately assume a pseudo stack. Ignore comment 2.

Shu, is this a profiler issue for not being correctly tagged as platform code? Ran into this a few more times when working with source maps (as these look like local files), and appears to be certain files maybe loaded from file:// rather than resource/chrome.

This can be reproduced by recording on a new tab, as pretty much all content should be platform content, but we get a handful of frames from `file://{path-to-my-gecko-checkout}/obj.noindex/dist/Nightly.app/...` -- I wonder if we can just say if the URI is "dist/Nightly.app/Contents/Resources/components" (for each operating system), or if these scripts should be served over resource:// in the first place.

Triaging. Filter on ADRENOCORTICOTROPIC (yes).