There's been some recent controversy over access to & control over site JS
which I'd prefer not to wade into... but it does remind me of some ideas
I've been mulling over related to sandboxed JavaScript execution.
Power users need to have an easy way to write, deploy, and use tools that
integrate into the wikis:
* custom editing tools
* custom menu items
* custom widgets for the sidebar
* that can be enabled widely with a minimum of security worries
(We can make separate tools on Tool Labs already but that provides no UI
integration beyond putting links in sidebars or wiki pages.)
JavaScript code can be isolated from the primary execution context by
running scripts in an <iframe> based on a distinct domain, with a
well-defined "safe" communication channel between it and the parent window
over the window.postMessage interface.
I've experimented with this previously in Extension:EmbedScript
<https://www.mediawiki.org/wiki/Extension:EmbedScript>to try "interactive
media"-like things such as graphs with dynamic components or graphical
quizzes/games. But I think this could be generalized to utility scripts
that hook up to a well-defined portion of the UI or a particular data
pipeline.
For instance, a custom citation editor tool might add a toolbar button in
the editor (via defined API), then accept input data and be given a chance
to display its own UI on activation in a floating iframe, just as if it
were a 'native' lightbox-style dialog; on completion it would send the
modified text back into the editor through the defined postMessage API, and
the editor would save it into the page.
Such a tool would be unable to, say, edit other pages on your behalf
unexpectedly, and it would be unable to have side effects on the rest of
the UI, but it could be safely selectable on-wiki through an interface like
selecting Gadgets...
And that limited integration means much better security and stability
controls than gadgets and user scripts can provide today -- a broken or
malicious sandboxed widget would only be able to do things you explicitly
permit it to.
This sort of clean/limited in-wiki script API might allow for a lot of the
stuff that site scripts and auto-enabled Gadgets are used for today,
without the related QA, security, and control/side-effect issues.
If folks think this is an interesting idea I'll pick it back up in my
research time as I get some of the video stuff I've been working on
finished up.
(Note I'm still in the UK for another week and a half, so I'll be
reading/replying on lists intermittently until I get back to SF.)
Thoughts on specific classes of tools that might be easy or hard to do with
this technique are welcome.
-- brion