https://bugzilla.wikimedia.org/show_bug.cgi?id=55642
--- Comment #1 from Krinkle <[email protected]> --- +1. Unsorted brain dump follows. If we're already inside a Worker and want it to fetch code: We could use postMessage to communicate with mw.loader and have it deliver the implementation of the module instead of executing it in the parent page. Since implementation are nicely self-contained it should be relatively straight forward (it has a reference of the closure which can be stringified and evaluated elsewhere). I've been thinking about a different feature that warrants similar handling, namely storing/caching of modules in localStorage. The tricky part is that some modules, especially in debug mode, return one or more urls instead of a closure. So we'd need to fetch those inside the worker presumably (the raw url type of resource executes immediately without a closure), however a Worker can't have a cross-domain injection like <script> can in the parent page. Anyhow, we could ban those modules initially and debug mode would simply not work in its current form (though I've been thinking about ridding debug module as it is and replacing it with sourcemaps instead, debug mode causes too many problems). Alternatively we could instead require the worker logic to be a module of its own, so instead of trying to fetch from mw.loader within a worker, we could say something like mw.loader.loadInWorker( .. ) which create a Worker instance and give it a url to load.php and a special parameter that makes load.php respond without the mw.loader.implement closure, and resolve dependencies and in the right order server-side. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
