Confirmed users
161
edits
User:Asqueella/JEP 107: Difference between revisions
m
→ScriptMod constructor
| Line 60: | Line 60: | ||
** When the provided value is an array, its items are expected to be functions. Non-function values are ignored. | ** When the provided value is an array, its items are expected to be functions. Non-function values are ignored. | ||
** The specified functions are called in order when a page matching the <code>include</code> rules starts to load (but before any content is loaded in the page -- i.e. when the <code>content-document-global-created</code> notification implemented in {{bug|549539}} is issued). An exception thrown from one of the functions does not stop the rest of functions from executing. | ** The specified functions are called in order when a page matching the <code>include</code> rules starts to load (but before any content is loaded in the page -- i.e. when the <code>content-document-global-created</code> notification implemented in {{bug|549539}} is issued). An exception thrown from one of the functions does not stop the rest of functions from executing. | ||
** The specified callbacks are called with a single <code>wrappedWindow</code> parameter -- the content's <code>window</code> object wrapped in an XPCNativeWrapper. The callback's <code>this</code> is the page mod object ('''TBD''' not currently implemented). | ** The specified callbacks are called with a single <code>wrappedWindow</code> parameter -- the content's <code>window</code> object wrapped in an XPCNativeWrapper. The callback's <code>this</code> is the page mod object ('''TBD''' not currently implemented). It goes without saying that with this syntax the callbacks are run in the calling module's scope, not in the content page's scope. | ||
===== | Creating a <code>ScriptMod</code> instance automatically enables it, so that the script mod takes effect on any matching pages that start to load after it's created. | ||
Enabling a script mod does not apply it to existing matching pages. | |||
To stop a script mod from running on further pages, call <code>scriptMod.disable()</code>. This does not undo the mod's effects on already loaded pages. | |||
===== ISSUE: What format should be chosen for <code>include</code> rules? ===== | |||
First, a short survey of existing formats: | First, a short survey of existing formats: | ||
* [http://wiki.greasespot.net/Include_and_exclude_rules Greasemonkey scripts] specify include and exclude URLs, each may contain wildcards ("*") in any location and may use a special ".tld" domain. These rules get compiled to a regular expression (see [http://github.com/greasemonkey/greasemonkey/blob/master/content/convert2RegExp.js convert2RegExp]), which is then matched against every URL loaded in the browser. | * [http://wiki.greasespot.net/Include_and_exclude_rules Greasemonkey scripts] specify include and exclude URLs, each may contain wildcards ("*") in any location and may use a special ".tld" domain. These rules get compiled to a regular expression (see [http://github.com/greasemonkey/greasemonkey/blob/master/content/convert2RegExp.js convert2RegExp]), which is then matched against every URL loaded in the browser. | ||
| Line 77: | Line 83: | ||
This is how I've arrived at the format described above. | This is how I've arrived at the format described above. | ||
===== Other issues ===== | |||
* There's no easy way to clean up objects referenced from the web page (event listeners, exported APIs) when a jetpack using script mods is unloaded. | |||
* Since the design makes a promise to let one module hosting the script mod to touch a random set of sites, it's not clear if this is going to work well in the out of process tabs world. | |||
* Should provide an example of using jQuery in a script mod. It's likely possible, but not obvious, given that the script mod runs in a hosting module's scope. | |||
==== <code>ScriptMod</code> APIs ==== | ==== <code>ScriptMod</code> APIs ==== | ||