Last modified: 2014-02-12 23:46:05 UTC
Deploying JavaScript live to servers via Mobile.js is not the best idea, however whilst Mobile.js exists it is very easy to be tempted to do so. No projects to my knowledge are using Mobile.js and whilst it exists it opens up a temptation to use it instead of going through a code review process. On Friday, whilst working with the legal team I deployed some code [1] via it which looked harmless and seemed to work on various browsers but over the weekend it transpired that it had broken mediawiki.org on various iPhones and Firefox (see bug 53941). I personally think we should kill it before we run into other problems. It is an unnecessary source of complexity in our JavaScript stack.. thoughts? [1] https://www.mediawiki.org/w/index.php?title=MediaWiki:Mobile.js&diff=779380&oldid=776995
(In reply to comment #0) > > No projects to my knowledge are using Mobile.js and whilst it exists it opens > up a temptation to use it instead of going through a code review process. > https://en.wikipedia.org/wiki/MediaWiki:Mobile.js has some custom code.
That bug was most likely caused by bug 50746. Killing the feature seems like throwing the baby out with the bathwater. The simplest workaround would be to make the mobile.js script load at position=bottom like all other site scripts.
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/mobile/cards/1190
FWIW I'm playing devils advocate. There have been many occasions when Mobile.css has caused bugs, but this page is much more widely used than Mobile.js If a feature is not being used I suggest we kill it or at least temporarily disable it. I hadn't realised en.wiki was using it - thanks Legoktm for pointing out, although this use case seems like it would be better done in the code repository itself since it is targeting beta and alpha modes and this code will also run on stable regardless.
I'm not sure screwing up a JavaScript edit necessitates disabling on-wiki JavaScript editing. I agree with comment 2 that this feels like overkill.
I also don't think that restricting people's customization abilities is helpful.
(In reply to comment #6) > I also don't think that restricting people's customization abilities is > helpful. Yes, this. To elaborate a bit just for clarity, MediaWiki has always strongly encouraged wiki admins and other users to make JavaScript and CSS changes on-wiki rather than mucking around in the actual CSS/JS skin files. This allows for easier upgrades, revision control, better accountability and transparency, etc.
There was a mail on the QA mailing list today investigating an issue which turned out to be due to an edit to Common.js: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki%3ACommon.js&diff=63247&oldid=58733 I really think having two avenues where JavaScript can get into a site is asking for trouble and wasted developer time and if it's barely being used I would be tempted to explore other avenues which solve the problem that it is trying to solve (and this problem works both ways - it seems wiki admins are unfamiliar with changes made in the mobile site code - so better transparency all round would be a good thing).
(In reply to comment #8) > There was a mail on the QA mailing list today investigating an issue which > turned out to be due to an edit to Common.js: > http://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki%3ACommon. > js&diff=63247&oldid=58733 That is neither Mobile.js nor an edit by a staffer, so I don't see how it's relevant. That's an edit by somebody using a testing wiki for its intended purpose.
Who am I kidding - you wiki guys are too crazy to ever let me disable it as much as I want it so I'll WONTFIX it to clean up the bugzilla bug queue. Instead I'll now focus my attention on making sure we enable MediaWiki:Common.php and MediaWiki:Mobile.php instead to make the point. Watch this space and be afraid you've brought this on yourselves...
