xpi build mode to bundle pre-packaged user scripts

http://arantius.com/misc/greasemonkey/script-compiler ?

It seems a bit behind the times (no console object, for instance), but if it meets the specs above otherwise, I'll consider patching that up to present standards instead. Will that render users with a Greasemonkey installation, complete with GM's security updates and script management interface?

(I don't want to give users ten different GM-derivate extensions, if they want to run ten user scripts distributed this way, just offer a comfy one-click install, whether they already had GM installed or not.)

Oh, I should add something so that at least calling console doesn't fail, good point.

And no, this makes a self contained extension. To the sort of end user who is incapable of installing GM and a user script on their own, I severely doubt it matters, though. I'm not sure how great the benefit is to such a system, while I am confident that hidden security problems would abound.

Given the initial reference to the Google bundle, mayhaps you should take their approach: GM, like FF, is open source. If you want to bundle it with something else, repackage and host it yourself.

The equivalent of a make target for bundling Greasemonkey with pre-installed scripts is what this ticket is about, yes, using that same approach. For instance in the form of a directory of user scripts, which, if present when you run build.sh, packs up those with the resulting xpi.

(The reason I'm opening a ticket and offering the code to do it back to the project is to have others wanting to do the same not have to find my code to do it somewhere else, and to have it maintainable in concert with the Greasemonkey code base, in case I don't maintain it and others would. And that it's good form. Maybe I want the wrong things or don't grok what proper procedures are, but I try my best after what little guidance is available.)

This sounds like a great idea to me, it is definitely a need. Should not be hard to do. The main thing is integration with amo. I can't think of anyway that you can make this work and point to the official site.

Also you'd want to figure out where the install dialog would go.

Maybe instead of bundling, it should be a feature that makes initial installation easier. For example, GM could have a protocol where a script would set a certain cookie or value in localstorage (the name/value pair store that's in FF2) and after installation, GM would read it to:

a) No what site to load on restart b) No what scripts to go get off uso and install

I think I've messed up this ticket's thought space a bit with this out-of-band mail on GM-dev, suggesting a more complex approach/mode of implementation than discussed above:

http://groups.google.com/group/greasemonkey-dev/browse_thread/thread/84f54a7340488cb9/313bad9a0d9b9f7b?rnum=1#313bad9a0d9b9f7b

Am I right in thinking that the basic approach I've outlined in this ticket is trivial? -- just zipping up some scripts (and maybe, but probably ideally not, a matching config.xml) inside the xpi, yielding a 3rd party GM-with-goodies.xpi, pointing at amo and otherwise being the equivalent result to an install of GM plus user interaction to find and install whatever scripts came bundled in GM-with-goodies.xpi?

I think the bit I don't recall is how an extension is bound to its integration with the updates system, and what URL gets polled for updates. If that is the installation URL, these days (it used to be an RDF url you could specify in install.rdf, IIRC), it might make sense to take the more advanced approach with giving Greasemonkey proper a two-tier installation protocol, allowing a pre-scripted post-(extension-)install automated progression of scripts to load and install. This could be a (very basic) wizard starting with a brief canned welcome and explanation of what the dialog or dialogs to come is about, optionally enlightened with a trailing message from the author (marked as such) with additional details.

If RDF updates url is still supported by firefox, and amo provides such an url to point to, I think that would be the place to start. I wouldn't mind going down the installation protocol path too, once I have the basic mode working.

Replying to ecmanaut:

I think the bit I don't recall is how an extension is bound to its integration with the updates system, and what URL gets polled for updates.

It's based on the extension ID. For GM, it's {e4a8a97b-f2ed-450b-b12d-ee082ba24781}. For extensions installed from a.m.o, the update url is based purely off of that.

Distributing a version of Greasemonkey with scripts pre-installed is not even a Greasemonkey ticket. Just put the scripts in the config folder, rezip, and deploy.

The only problem with this is that you need to update this whenever Greasemonkey updates. Also it's not reusable for the greater GM community.

I propose a minor change to GM that would do the same thing, and solve these two issues:

* When Greasemonkey is run the first time, it looks for a special value in DOMStorage (http://developer.mozilla.org/en/docs/DOM:Storage#globalStorage). For example, globalStorage[].greasemonkey_autoinstall_scripts.

* If there is anything there, it goes and grabs these scripts (just URLs) and installs them, using the regular ScriptDownloader? mechanism.

• You'd have to modify ScriptDownloader? to be able to install silently.

* Next, it looks for globalStorage[].greasemonkey_redirect_url. If there is anything there, Greasemonkey opens a foreground tab to that page.

This would allow anyone to put a link on their site that installs Greasemonkey with their script. For example:

<a href="#" onclick="handleInstallScript()">Get myscript!</a>

function handleInstallScript() {

if (hasGreasemonkey) {

this.href = "myscript.user.js";

} else {

globalStorage[].greasemonkey_autoinstall_scripts = myscript.user.js?; globalStorage[].greasemonkey_redirect_url = location.href; this.href = "http://addons.mozilla.org/url/to/greasemonkey.xpi";

}

}

There are ways to determine hasGreasemonkey now, but it would be nice for us to advertise better. We could just add something to unsafeWindow, like unsafeWindow.greasemonkey = true, but that is probably a separate ticket.

Thoughts?

+1, at least at large. (I'd rephrase the href to link the script, and onclick something like "return hasGreasemonkey installWithGreasemonkey();", to remain REST friendly.)

It's conceivable parts of the web would respond badly to growing Greasemonkey detection capability, but I would call it, at the very least, worth testing.

So is this something you're interested in taking on Johan?

Sure. I have two minor conflicting gut feelings about naming, though, and an opposing candidate "GM.hasGreasemonkey", what I would like to screen through other devs' gut feelings.

Pros:

+ Cleaner forward path for any future extension of whatever kind (like collaborative application to application messaging between content / GM layers, like Gears' messaging system).

+ Rhymes well with where I think GM-side APIs are going.

Cons:

- Uglier interface consumer looks: `if (typeof GM == "object" && GM.hasGreasemonkey)'

It's probably easier/safer to export an object with properties.

Exposing XPCOM components in JavaScript, part one

That uncommented anonymous attachment seems to be a build from a few months old GM tree -- possibly with modded locale files, and, anyway, completely unrelated to this ticket.

(Can we turn off anonymous attachments, perhaps? It's a bit unnerving, and mostly feels like an attack vector against unsuspecting but curious GM users.)

Yikes! Some of the suggestions in here are quite scary about pre-bundling scripts into the amo distro. It would be smarter to prompt the user to visit a special u.s.o account (like userid 0) for a list of common trusted reliable scripts and let the user decide for themselves, imho.

That was not the intent; the a.m.o distro would remain free of extras; our aim was to make the a.m.o build able to be used to self-populate a script or a few, after it has installed, without additional dialogs or user interaction, to make user scripts easier for end users to get started with than they presently are. We unfortunately failed to come up with first an ungameable approach and, upon further research, even a working, approach, as localstorage at the time wasn't implemented by Firefox (it probably still isn't).

So the goal still is as per the ticket title, to streamline the process of building the mainine GM codebase, but including one or more scripts in the built xpi, which get pre-installed as soon as the extension is installed. Aaron hinted it might be as easy as documenting how to do that, but I never figured out how to (create a directory of the right name with the scripts in the build directory?), but I would presume build.sh and perhaps the javascript code setting up the config directory may need a tweak too.

For an end user incapable of pre-screening code him/herself, it's exactly as scary or unscary as installing any unsigned or un-peer-reviewed user script or extension -- no more, no less.

Hosting this capability from within the GM code tree itself beats the script compiler referenced in comment 1 in at least three ways: we spread GM, users get free updates to GM, and the script compiler gets free updates from GM development, whenever the GM codebase moves forward.

江苏省顺利牧业是一家专业从事良种瘦肉型仔猪繁育、仔猪销售的独资企业。基地成立以来，一直深受省、市、县三级领导的关心与扶持，年年被评为诚实、守信企业，全国外三元育种协作组成员单位，经过不断的扩建,和仔猪品种的改良,基地常年面向全国供应25-110斤长白、杜洛克、双肌臀大约克、内 外三元、纯种四元优质瘦肉型苗猪， 养猪基地所有繁育场采用科学节约化繁育管理，技术质量高，抗病能力强、成活率高。目前加盟我公司连锁大型猪场已达50多家，确保质量。 基地主防：口蹄疫、链球菌、蓝耳病、弓形虫猪圆环病毒、二型混合感染等。 目前公司苗猪远销：苏、沪、浙、皖、鄂、赣、豫、湘、京、冀、晋、陕、新、粤、闽以及东北三省，内蒙等地。让每一个客户都能在顺利苗猪繁殖场,买到良种瘦肉型苗猪是公司最根本宗旨！

1、建立外贸型公司，原料、市场、技术、人才、资金、信息等资；

2、利用现代电子信息技术，建立和完善顺利牧业的电子商务系统和计算机管理系统，实现网上的物流管理，网下的配送服务；

http://opisygg.qqryk.pl/

Getting back to this, why would this newly bundled .xpi need to be constantly updated? It would still poll the "official" GM update.udf, so the worst case scenario is someone installs an "old" version of GM pre-bundled with some userscript and then immediately gets an update, without losing the bundled script.

Or am I missing something?

Replying to boo..@youngpup.net:

Distributing a version of Greasemonkey with scripts pre-installed is not even a Greasemonkey ticket. Just put the scripts in the config folder, rezip, and deploy.

I tried this and it didn't work (create a config/ folder in the xpi and put the userscript there). Did I misunderstand? Have things changed?

I can say for sure that right now, [http://greasemonkey.devjavu.com/browser/trunk/src/chrome/chromeFiles/content/config.js#L345 _initScriptDir()] only creates the directory then puts a config.xml there, and no more.

If I go way back in time, I find [http://greasemonkey.devjavu.com/browser/trunk/src/chrome/chromeFiles/content/versioning.js?rev=365#L32 GM_pointFourMigrate()], which seems to do just about the same. I think you have to go way back to find a GM that was capable of bundling scripts.