Earlier this week (http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057638.html), I wrote about the upcoming 1.19 release and the changes that need to be made on-wiki to provide a consistent experience.
I've been thinking about this and getting input from on-wiki administrators, but I'm interested in your thoughts,
I have talked to Krinkle and I realize his concerns -- javascript dependencies really should be enumerated. Still, I'm concerned about the experience for users who have installed several gadgets (which we can test in Krinkle's "Tour de Wiki") as well as possible UserScripts (which we really can't test, at least not at as easily or as quickly).
I adjusted the [[MediaWiki:Gadgets-definition]] on enwiki.beta and let the people on enwiki know what I had found, but I think this sort of adjustment will be needed in more places. For proof, just look at http://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Hauptseite?debug=true in FireBug.
You'll see (or, at least, I see) two un-fulfilled dependencies on mw.util.
Some sort of dependency needs to be added on mw.util -- either just preload it or make it log a message when there is an unenumerated dependency on it (and other necessary js dependencies).
This, plus a message on WP:VPT or the like, would be a way for users and gadget authors to update their javascript. It be a great way to notify users of the deprecation from 1.18 to 1.20 (or 1.21) without providing a horribly shocking experience after we upgrade the cluster.
Let's ensure that the Wiki* experience is consistent. We can avoid some of the mistakes like those that happened when we introduced ResourceLoader. Backwards compatibility is important. If we upgrade MediaWiki and we know that people are going to complain because a widespread dependency (like mw.util) disappeared, let's eliminate that "experience gap".
Mark.
Hi,
Thanks for bringing this to wikitech-l.
On Sat, Jan 21, 2012 at 4:25 AM, Mark A. Hershberger < mhershberger@wikimedia.org> wrote:
I adjusted the [[MediaWiki:Gadgets-definition]] on enwiki.beta and let the people on enwiki know what I had found, but I think this sort of adjustment will be needed in more places. For proof, just look at http://de.wikipedia.beta.wmflabs.org/wiki/Wikipedia:Hauptseite?debug=true in FireBug.
You'll see (or, at least, I see) two un-fulfilled dependencies on mw.util.
One exception is thrown due to references to code from the "mediawiki.util" module (missing dependency) and two errors due to missing a dependency on "mediawiki.user". Which shows that the problem is not limited nor specific to the "mediawiki.util" module.
I've also spotted a fair number of gadgets missing dependencies on "jquery.cookie" during the tour. Basically any references to module code written by users that didn't know about dependencies is going to fail. As of writing there are 115 different modules in core that contain one or more javascript files.
Some sort of dependency needs to be added on mw.util -- either just
preload it or make it log a message when there is an unenumerated dependency on it (and other necessary js dependencies).
I think we should attempt to complete the tour (at least the adding of dependency information) for all wikis before deployment, that's the only real fix for the problem and should've happened in the first place. If after deployment it would turn out that there is still a large number of scripts floating around without dependency info, we could add the most common ones unconditionally to the pre-load startup stack which currently only contains "jquery" and "mediawiki".
Such measure should be temporary, because it would cause confusion if some modules work without dependencies info and others don't. i.e. what if next up is a bug report about another dozen modules that people often use but aren't declared in their dependencies and causing problems. It should not become "normal" that code works without declaring dependencies. Especially if new gadgets are written based on others that don't either. These "copied habbits" are very common, and is how most users learn what is "right". In my perception this is how the vast majority of javascript code has been saved to wiki pages so far (both to good and bad ends).
Or to put it boldly vice versa: It should be perfectly normal for code to explode if it's missing a dependency (I'd rather have it explode on-save for it to be fixed right away, then it silently working because another gadget happens to be loaded first is providing the required module to the scope).
However such explosion (or logging a message as you suggest) about a dependency missing is unlikely to occur when it should. JavaScript is simply too dynamic to extract this information. Objects and functions can be aliased, code can be conditionally loaded, code an be lazy-loaded with inline dependencies and more. And most commonly, modules loaded as dependency for one module are also available to all future modules (i.e. if module A and B both use module C, but only A is declaring it's dependency on C. Then loading A and B will likely succeed without error because C is only loaded once and when B is executed, it's already there). To complicate it further, this scenario (only having to load each module once) is actually a major feature of resource loader, not a bug.
Some examples here may be exaggerated, I'm not saying they are going to happen if this and that etc., but I'm being cautious because I'm afraid there's no harmless way back.
This, plus a message on WP:VPT or the like, would be a way for users and
gadget authors to update their javascript. It be a great way to notify users of the deprecation from 1.18 to 1.20 (or 1.21) without providing a horribly shocking experience after we upgrade the cluster.
I agree. I've updated the migration guide[1] with Edokter over the past week, including common mistakes and their (simple) solutions. So let's spread the word about it[1] now. So that it may complete before 1.19 deployment. We should include in communication that this is required for ResourceLoader since 1.17 and becomes extra important with the load queue improvements coming in 1.19. Since faster loading makes race conditions in dependency resolving more likely to fail, that is - if dependencies are not declared for all or only few of gadgets. Thanks, - Krinkle
[1] https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users%29
On Fri, Jan 20, 2012 at 7:25 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Let's ensure that the Wiki* experience is consistent. We can avoid some of the mistakes like those that happened when we introduced ResourceLoader. Backwards compatibility is important. If we upgrade MediaWiki and we know that people are going to complain because a widespread dependency (like mw.util) disappeared, let's eliminate that "experience gap".
Thanks for posting this to the list. I've highlighted above the most important part of what you wrote -- we will not introduce known incompatibilities and count on our ability to clean these things up after the fact unless that's the only way to do it. My understanding is we have far better options in this case, and we'll have more than enough work on our hands cleaning up after unknown incompatibilities.
A couple of relevant bugs: Bug 33711 - mw.util.$content is undefined in MediaWiki:Common.js https://bugzilla.wikimedia.org/show_bug.cgi?id=33711
Bug 33746 - Resource Loader should pre-depend on mw.util https://bugzilla.wikimedia.org/show_bug.cgi?id=33746
Roan should be weighing in on these soon. My understanding is that he plans to add the necessary dependency to make this work.
Rob
On Wed, Jan 25, 2012 at 7:35 AM, Rob Lanphier robla@wikimedia.org wrote:
A couple of relevant bugs: Bug 33711 - mw.util.$content is undefined in MediaWiki:Common.js https://bugzilla.wikimedia.org/show_bug.cgi?id=33711
Bug 33746 - Resource Loader should pre-depend on mw.util https://bugzilla.wikimedia.org/show_bug.cgi?id=33746
Roan should be weighing in on these soon. My understanding is that he plans to add the necessary dependency to make this work.
These were fixed a little while ago by loading mw.util and its dependencies early. This means that any JS that uses mw.util but doesn't explicitly declare this dependency will continue to work, because mw.util will be one of the first things to be loaded (before any on-wiki JS) and will always be loaded regardless of whether any module indicates they need this or not. However, ideally people shouldn't rely on this behavior (it probably won't be this way forever, as we'll try to get rid of these early-loading privileges where we can), and should always list all dependencies a gadget or user script uses.
The following modules are loaded early and are always present: mediawiki.page.startup mediawiki.legacy.wikibits mediawiki.legacy.ajax (pending merge of r111034 into 1.19) mediawiki.util (listed separately, but would be loaded anyway because page.startup depends on it)
Additionally, the following modules are also loaded early and always because one of the three modules above depends on them: jquery.client (dependency of mw.page.startup and mw.util) jquery.cookie (dependency of mw.util) jquery.messageBox (dependency of mw.util) jquery.mwExtension (dependency of mw.util)
You should rely even less on this second set of modules being magically present, because these dependencies might be factored out and disappear unannounced.
I believe this should address everyone's concerns about JS breakage in 1.19 (I've put in workarounds for every kind of breakage I've seen or could think of), but if there are any outstanding issues or concerns feel free to talk to me on-list or off-list.
Roan
wikitech-l@lists.wikimedia.org