<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/04/2015 16:17, Bill McCloskey
wrote:<br>
</div>
<blockquote
cite="mid:CAJ6cW=NUcyUrCBnpsuP7ubO5-atqsk3dMgRpR91Kfy8gQUo=Sw@mail.gmail.com"
type="cite">
<div dir="ltr">On Fri, Apr 3, 2015 at 8:02 AM, Gijs Kruitbosch <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span>
wrote
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> AIUI, jsms are our next-best alternative, but
using a lot of them has serious performance downsides
(and will also require a bunch of refactoring for the
included scripts).<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>We already import ~50 JSMs into browser.js. Converting
21 #include files to JSMs will be annoying, but I doubt it
will have any significant effect on performance. We'll use
a little more memory, but the code will be loaded more
lazily in most cases. It's worth measuring though.<br>
</div>
</div>
</div>
</div>
</blockquote>
There are bugs on file to save even using 1 extra JSM (
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=986503">https://bugzilla.mozilla.org/show_bug.cgi?id=986503</a> ) so 21 extra
JSMs does not sound nice.<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<blockquote
cite="mid:CAJ6cW=NUcyUrCBnpsuP7ubO5-atqsk3dMgRpR91Kfy8gQUo=Sw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> Perhaps we can introduce a valid JS shorthand to
include extra files by simply loading them into the
global scope with the scriptloader, and then
preprocess them for dist and/or pgo builds?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Well, the point of removing the preprocessor is to use
only standard JavaScript, so I don't think we should do
that.<br>
</div>
</div>
</div>
</div>
</blockquote>
I think you misunderstood my suggestion. I'm saying we should write
a function (e.g. in utilityOverlay.js) that looks something like:<br>
<br>
function import_script(url) {<br>
var sl = Services.scriptloader;<br>
sl.loadSubscript(url, this);<br>
} // not actually tried this, but the idea should be clear!<br>
<br>
and then use
import_script(<a class="moz-txt-link-rfc2396E" href="chrome://browser/content/browser-whatever.js">"chrome://browser/content/browser-whatever.js"</a>);<br>
<br>
Using a separate function makes it easy to apply build-time grep
magic to inline the file in optimized builds.<br>
<br>
As an extra (opaque) function call is valid JS, it wouldn't break
preprocessors and avoids the refactoring and memory overhead of
JSMs. We could always switch to using JSMs as/where appropriate.<br>
<br>
<blockquote
cite="mid:CAJ6cW=NUcyUrCBnpsuP7ubO5-atqsk3dMgRpR91Kfy8gQUo=Sw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> For CSS (which has this problem but worse because
no scriptability) we can presumably do this with the
pre-existing @import , and change %defines to use CSS
variables?</div>
</div>
</blockquote>
<div><br>
</div>
<div>That would be cool. I'm also worried about .xul files.
It would be great to get rid of the preprocessor in those,
but I don't know of any replacement for #ifdef in XUL.<br>
</div>
</div>
</div>
</div>
</blockquote>
XUL overlays would be one. Don't know what the runtime/memory
overheads of that would be.<br>
<br>
JS adjustments and hidden="true" on the markup you usually don't
want would be another option. Could probably decide on a
case-by-case basis.<br>
<br>
~ Gijs<br>
</body>
</html>