<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 18, 2018 at 10:54 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Err, so it seems a side-effect of this (which wasn't very obvious to me when this was posted) is that it's now no longer possible to change a .idl file for a JS component in an artifact build and have it "work".<br>
<br>
Specifically, I ran into this when changing the return type of an extant idl method for nsBlocklistService.js from `unsigned long` to `jsval` (making the method async). I spent a good few hours being puzzled as to how callsites using `await` were getting 0 when the callee was (asynchronously) returning non-zero things, and why the logs from the caller and callee were out of order. Turns out, xpconnect and friends will happily silently convert things (in this case, a Promise object) to match the declared return type (ending up with NaN/0).<br>
<br>
TL;DR: the effect on artifact build users seems pretty unfortunate. Given that we're also not supposed to be making new JS-implemented webidl things, what's the long-term plan for artifact build support for changing JS-implemented interfaces?<br></blockquote><div><br></div><div>Sorry for the hassle. I guess we should at least produce some kind of error, or at least not run the XPIDL compilation stuff at all in artifact builds. I saw there was some manifest stuff for artifact builds, so I didn't realize it would work.</div><div><br></div><div>Potentially we could reimplement some dynamic loading (at browser startup time) to support this in artifact builds, but yeah like Kris said, this will have only ever worked in the JS-to-JS case.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
~ Gijs<br>
<br>
On 04/04/2018 21:10, Andrew McCreight wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I recently landed bug 1438688, which makes it so that we don't ship XPT<br>
files any more, so they don't need to be added to a <a href="http://package-manifest.in" rel="noreferrer" target="_blank">package-manifest.in</a><br>
file. (Instead, the XPT information is compiled into the binary.) I think<br>
it'll give you an error if you add it anyways, but I haven't tested it. We<br>
still use XPT files during the build process, so you'll see them appear in<br>
your build log spam as usual.<br>
<br>
Andrew<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div></div>