Confirmed users
161
edits
User:Asqueella/JEP 107: Difference between revisions
Jump to navigation
Jump to search
→Discsussion - script context in Model C: update with the latest dicsussion
(→Discsussion - script context in Model C: update with the latest dicsussion) |
|||
| Line 173: | Line 173: | ||
A few issues here: | A few issues here: | ||
* At which point does the separate script run, how does it declare it wants to do something on-window-created or on-DOM-ready. | * '''[RESOLVED]''' At which point does the separate script run, how does it declare it wants to do something on-window-created or on-DOM-ready. | ||
** | ** (Chrome has "run_at" option in the content script's manifest, which defaults to "document_idle" meaning "sometime between DOMReady and soon after onload" with other options being DOMReady and WindowCreated. It's not clear how important this is for performance and why.) | ||
** Since we want to make it possible to run code on-window-created to install APIs, we'll run the pagemod script before load starts and provide onReady callback or have a DOMContentLoaded example in documentation. | |||
* '''[UNRESOLVED]''' How do we let the script include common libraries / modularize its code | |||
** | |||
* How do we let the script include common libraries / modularize its code | |||
** [Nickolay] Chrome lists the scripts to be loaded (in the single content script context) in order in the manifest. Simple and similar to web pages, but different from jetpack execution model. | ** [Nickolay] Chrome lists the scripts to be loaded (in the single content script context) in order in the manifest. Simple and similar to web pages, but different from jetpack execution model. | ||
** Possible option: provide <code>require()</code> to content scripts, like in the main jetpack | ** Possible option: provide <code>require()</code> to content scripts, like in the main jetpack | ||
*** Pros | *** Pros | ||
**** [Myk/Brian] we do need a way for the mod context to access self.data.url, JavaScript libraries like jQuery, and probably some other functionality. And modules are our hammer. | **** [Myk/Brian] we do need a way for the mod context to access self.data.url, JavaScript libraries like jQuery, and probably some other functionality. And modules are our hammer. | ||
**** [[http://groups.google.com/group/mozilla-labs-jetpack/msg/b6a054635076a25e Myk]] there is a long tail of built-in functionality that page mods might want to access [..] We could design another mechanism to expose APIs to page mod modules, but that mechanism would either be [..] limited [..] duplicate what "require" already provides. | |||
***** [[http://groups.google.com/group/mozilla-labs-jetpack/msg/42ff72faf47e91f3 Benjamin]] strongly disagree here. Page mods, if they wish to access all these other bits, should use message-passing to the main addon code. | |||
*** Cons | *** Cons | ||
**** [Myk] a bit worried about the potential for confusion due to conflating the two spaces by providing both with the same interface for importing functionality but not allowing one to import the same functionality as the other. | **** [Myk] a bit worried about the potential for confusion due to conflating the two spaces by providing both with the same interface for importing functionality but not allowing one to import the same functionality as the other. | ||
| Line 188: | Line 188: | ||
** [Brian] Perhaps the first release will not provide a require() function, and then later (once we figure out our story for the "search path" for this context and how it differs from the other modules), we can make it available. | ** [Brian] Perhaps the first release will not provide a require() function, and then later (once we figure out our story for the "search path" for this context and how it differs from the other modules), we can make it available. | ||
** [Brian] I'm vaguely thinking that the PageMod() constructor, next to the script: argument, could provide a list of libraries that are made available to that script. Maybe a mapping, like: <code>scriptlibs: { jquery: data.url("jquery.js") } }</code>. Allowing my-example-org-mod.js to use: <code>var jq = require("jquery");</code> | ** [Brian] I'm vaguely thinking that the PageMod() constructor, next to the script: argument, could provide a list of libraries that are made available to that script. Maybe a mapping, like: <code>scriptlibs: { jquery: data.url("jquery.js") } }</code>. Allowing my-example-org-mod.js to use: <code>var jq = require("jquery");</code> | ||
* What is the script's global, how does it access page's Window and Document | * '''[RESOLVED?]''' What is the script's global, how does it access page's Window and Document | ||
** [Nickolay] Both GreaseMonkey and Chrome create a clean object as the script's global with __proto__ set to XPCNativeWrapper(contentWindow) and necessary globals added to it (GM_*, chrome.extension.*) | ** [Nickolay] Both GreaseMonkey and Chrome create a clean object as the script's global with __proto__ set to XPCNativeWrapper(contentWindow) and necessary globals added to it (GM_*, chrome.extension.*). I think we should implement a scheme like GM's/Chrome's, since it will be the most familiar and intuitive. [[http://groups.google.com/group/mozilla-labs-jetpack/msg/b60602ab3bca1517 Myk] and [http://groups.google.com/group/mozilla-labs-jetpack/msg/42ff72faf47e91f3 Benjamin agreed this is a good solution for jetpack as well]. Other options are listed in Benjamin's message.] | ||
** [Brian] Passing the window as an argument [to a callback] (versus providing it to the whole module as a global) seems more in keeping with the "The Number Of Globals In A CommonJS Module Shall Be Two: require and exports" pattern. [...] | ** [Brian] Passing the window as an argument [to a callback] (versus providing it to the whole module as a global) seems more in keeping with the "The Number Of Globals In A CommonJS Module Shall Be Two: require and exports" pattern. [...] | ||
** [Nickolay] | *** [Myk,Nickolay] given that the sole purpose of "page mod" modules is to access the pages they are modifying, it's worth simplifying access to the "window" object by defining it globally | ||
* How does the script communicate with the main jetpack | * How does the script communicate with the main jetpack | ||
** GreaseMonkey defines several GM_* globals to provide additional functionality to GM scripts. | ** GreaseMonkey defines several GM_* globals to provide additional functionality to GM scripts. | ||
| Line 197: | Line 197: | ||
** [Nickolay] If we are going to allow exporting APIs (e.g. window.microphone) via this mechanism, we might need sync content->jetpack messaging. bsmedberg also mentioned this as a possibility. | ** [Nickolay] If we are going to allow exporting APIs (e.g. window.microphone) via this mechanism, we might need sync content->jetpack messaging. bsmedberg also mentioned this as a possibility. | ||
** [Brian] suggested a similar pipe-based mechanism: <code>onNewPage: function (pipe) {</code> in the ScriptMod options. "Instead of a "pipe" argument, maybe the onNewPage function should get a "control" object, from which it can manipulate the pipe, ask about the URL from which the target page was loaded, and register to hear about the page going away. The latter would be necessary for the all-volume-control jetpack to remove closed pages from its list." | ** [Brian] suggested a similar pipe-based mechanism: <code>onNewPage: function (pipe) {</code> in the ScriptMod options. "Instead of a "pipe" argument, maybe the onNewPage function should get a "control" object, from which it can manipulate the pipe, ask about the URL from which the target page was loaded, and register to hear about the page going away. The latter would be necessary for the all-volume-control jetpack to remove closed pages from its list." | ||
** [Benjamin] Start with something like <code>addon.postMessage(JSON.stringify(messageobj), '*');</code> to re-use existing DOM mindshare (this doesn't do RPC). | |||
=== TODO === | === TODO === | ||