1589665 - Help Searchfox understand SpecialPowers / SpecialPowers.spawn definitions

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

Tons of test code uses SpecialPowers.spawn and similar SpecialPowers APIs. The test-exposed logic currently is inferred as SpecialPowersChild.spawn because the implementing class name is SpecialPowersChild defined at SpecialPowersChild.jsm#152 with the SpecialPowers alias created by assigning to "SpecialPowers" in the given content window global at SpecialPowersChild.jsm#205.

I think it's reasonable to say that it's probably beyond the JS indexer's powers to infer the exposed-to-content name without a little help. I think it's also reasonable to say that we shouldn't require the code in question to rename SpecialPowersChild to SpecialPowers just for searchfox.

Options:

• Start supporting some JSDoc directives like alias.
• Add some heuristics that infer the alias. A lot of options here:
  • https://github.com/mozilla/doctorjs style abstract interpretation that notices the class subclasses JSWindowActorChild, assigns magic variable this.contentWindow to local window, then pokes into it.
  • Just look for the pattern window.wrappedJSObject.FOO.
• Some external config file where we just hardcode such aliases.

Important caveats:

• The JS indexer currently doesn't understand a symbol having two effective names, so a minor enhancement would be required for SpecialPowersChild to be known as both SpecialPowers and SpecialPowersChild.
• Indexing is currently single-pass, so any type of inference or logic where a descendant in the AST impacts the indexing of its ancestor/siblings would require an additional processing pass.
• Bug 1499066 covers trying to be fancier in terms of being aware of the realities of JS globals and how things get imported into globals. Right now we assume all JS code in the tree effectively lives in a single giant global which is far from the truth.

:kmag, any thoughts here as someone experienced in the webext world of poking stuff into globals and author of the specialpowers overhaul? I would lean towards very simple JSDoc annotation support. Like regex simple.

Comment 1

[Kris Maglione [:kmag]]

Renaming wouldn't help (nor would simple aliasing) because the properties you actually care about in these instances are SpecialPowersChild.prototype.spawn and so forth, not SpecialPowers.spawn, which is a different thing. I think what you really want is for Searchfox to assume that there's a SpecialPowers global defined everywhere that's an instance of SpecialPowersChild, but I don't know how simple that is.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

To be clear, the JS indexer is based on the reflect API, not evaluation, and doesn't introduce "prototype" anywhere in the symbols it generates. It also explicitly compensates for "prototype" when processing assignments[1]. If you click on "spawn" at https://searchfox.org/mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c/testing/specialpowers/content/SpecialPowersChild.jsm#1664 we already infer a symbol of "SpecialPowersChild.spawn" and generate a search link menu option with query https://searchfox.org/mozilla-central/search?q=symbol:SpecialPowersChild%23spawn&redirect=false but it's not useful because that's the only instance of that symbol anywhere.

1: https://github.com/mozsearch/mozsearch/blob/master/scripts/js-analyze.js#L840

Comment 3

[Kris Maglione [:kmag]]

OK. Well, as far as JS is concerned, properties of a constructor and of an instance are completely unrelated, so that sounds like a pretty broken way to handle things... but shrug