Confirmed users
161
edits
User:Asqueella/JEP 107: Difference between revisions
→Discsussion - script context in Model C: added section
(→API Methods: copy the suggested syntax for "C" (script: data.url()) from the groups thread) |
(→Discsussion - script context in Model C: added section) |
||
| Line 168: | Line 168: | ||
* Scripts in the original JEP run in the context of the page, while in this JEP they run in the jetpack context. Although it's an important feature, I think it can be implemented separately, since it requires substantially more effort and additional coordination for e10s. | * Scripts in the original JEP run in the context of the page, while in this JEP they run in the jetpack context. Although it's an important feature, I think it can be implemented separately, since it requires substantially more effort and additional coordination for e10s. | ||
* <code>add/remove/empty</code> methods on the page mod object were not included, since there's no clear use case for them, especially if the changes are not applied instantly, as in this proposal. | * <code>add/remove/empty</code> methods on the page mod object were not included, since there's no clear use case for them, especially if the changes are not applied instantly, as in this proposal. | ||
==== Discsussion - script context in Model C ==== | |||
Background: Chrome's [http://code.google.com/chrome/extensions/content_scripts.html Content Scripts] and [http://code.google.com/chrome/extensions/messaging.html Message Passing]. | |||
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. | |||
** [Nickolay] 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. | |||
** [Nickolay] There's an option of listing different files in ScriptMod options à la model "B", but it seems unnecessary complexity. | |||
** Myk and Brian used an example with callback functions (onStart, onReady) defined in the content script. | |||
** [Nickolay] Since the script must be evaluated onStart if it is to be able to do anything before the page starts loading, the onStart callback is actually redundant. We could either provide an easy way to register for DOMReady event or leave it to libraries. | |||
* 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. | |||
** Possible option: provide <code>require()</code> to content scripts, like in the main jetpack | |||
*** 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. | |||
*** 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. | |||
**** [Nickolay] we should also remember that the content scripts (and the related CommonJS machinery) will reload every single page load. I think that while the CommonJS hammer is attractive, the content scripts should generally not be as complex as to require it. We can add it later if there's need. | |||
** [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> | |||
* 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.*) | |||
** [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] I think we should implement a scheme like GM's/Chrome's, since it will be the most familiar and intuitive. The rare developers who want to use the principle of least authority can do so in the main jetpack (it can't be given access to any of the page's DOM anyway, so there's no reason to keep it in content process). | |||
* How does the script communicate with the main jetpack | |||
** GreaseMonkey defines several GM_* globals to provide additional functionality to GM scripts. | |||
** [Nickolay] Chrome implements bidirectional asynchronous message passing via <code>chrome.extension.sendReqest(json, responseCallback)</code> and another pipe (<code>Port</code>) based API for long-lived connections. | |||
** [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." | |||
=== TODO === | === TODO === | ||