Since the WhoWroteThat extension will be operating strictly on MediaWiki sites, and since we want to provide an experience that takes into account as many of the already-existing tools that MediaWiki offers (like right-to-left support, interface messaging, and access to tools that users are familiar with, like GuidedTour) we should check whether we can access, from within the browser extension code, the window global variable.
If we can do that, we can access things like mw.loader and mw.msg which would make development easier, maintainance easier, and help us provide the solutions we need and make them act and look like any other MediaWiki experience.
It appears browser extensions may allow for this inherently. Some resources:
- Mozilla seems to allow access to window global with Background scripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Anatomy_of_a_WebExtension#Background_scripts
- Chrome might enable this through window.postMessage https://developer.chrome.com/extensions/content_scripts#host-page-communication
We should investigate if this is doable and feasible in a way that is compatible with both Chrome and Firefox's requirements for security in their extension store.
Results of investigation
OK, it looks like there's agreement that the strategy is sound and acceptable. In that case, I am going to summarize it with an action plan for the team. Please see if this makes sense or if I missed anything:
Action plan
- The WhoWroteThat script can be written as if it is running from within MW infrastructure (just like a gadget)
- Our build step (currently using grunt, in the extension repo, but may change to use another tool) needs to do this:
- Concatenate all WhoWroteThat business-logic files into a single script, with two parts:
- a loader script: This attaches whatever trigger button we need on the page to activate the WhoWroteThat mode. This depends on jquery and mediawiki.base
- Business logic: The entire logic of presenting the results from Whocolor, popups, etc. This depends on OOUI.
- The "business logic" script can be wrapped with a mw.loader.using( 'ooui' ).then( ... ) statement, and then be included inside the loader script.
- The loader (that includes, within it, a lazy-loaded business-logic script) will be wrapped by a loading method.
- At the bottom of the concatenated file that has the loading function, we push the loading function into RLQ.
- We only need the jquery and mediawiki.base dependencies through the RLQ load.
- When the script sent to the RLQ runs, we have mw.loader.using available, so we can load the heavier dependencies only when we need them (when the toggle button is activated)
- Concatenate all WhoWroteThat business-logic files into a single script, with two parts:
- The entire file that was produced is our "web_accessible_resources" and is the file that the extension the injects into the DOM on Wikipedia sites that work with WhoColor
If this looks good and I didn't miss anything, I'll add some code snippets and put this up in the task description, so we can reference to it from our implementation tasks.
Here's what it should look like, generally:
function loadWhoWroteThat() { var $button = $( <a> ); // etc // CODE: Attach a toggle button somewhere in the DOM. jQuery is available. $button.click( function () { mw.loader.using( [ 'oojs-ui' ] ).then( function () { // CODE: This is handling the actual business logic of WhoWroteThat? service // pulling the API from WhoColor, replacing/toggling the new DOM, building // OOUI popups for viewing data about revisions, etc. } ); } ); } var q = window.RLQ || ( window.RLQ = [] ); q.push( [ [ 'jquery', 'mediawiki.base' ], loadWhoWroteThat ] );
Since this is the basic structure, our build step can allow us to work with individual files in development (meaning also allowing for proper unit tests, etc) and then build the files into the above structure.