Developer Wishlist/2017/Frontend

Remove IE8 hacks/workarounds/etc. from extensions
As of rMWdf1019c49d30: startup.js: Move IE8 down from Grade A to Grade C, MediaWiki no longer serves JavaScript to IE8 users. There are a lot of IE8 hacks lying around that can now be removed. grepping for "IE8" will likely find a lot.

Support (T123218)

 * 1) David1010 (talk) 06:40, 6 February 2017 (UTC)
 * 2) Consulnico (talk) 09:35, 6 February 2017 (UTC)
 * 3) Ladsgroup (talk) 09:58, 6 February 2017 (UTC)
 * 4) ThurnerRupert (talk) 12:02, 6 February 2017 (UTC)
 * 5)  ·addshore·  talk to me! 12:16, 6 February 2017 (UTC)
 * 6) Amir E. Aharoni (talk) 13:47, 6 February 2017 (UTC)
 * 7) Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)

Core should be aware of the domain it is running on and render mobile domains where necessary
Whenever a link to a desktop url is rendered on a mobile page, clicking it can take you to the desktop site (or at best cause you to go through an unnecessary redirect loop). This impacts Flow, Echo, MobileFrontend (languages) and causes lots of development pain.

A call to  or   should be aware of the domain it is running on and give the correct result.

Endorsements (T156847)

 * 1) In Wikipedia Zero this stuff required a fair amount of debugging, so resolution if it would be nice for consistency's sake. It's true, of course, that upon fixing this extensions that are impacted would need some TLC to ensure non-breakage. ABaso (WMF) (talk) 18:11, 6 February 2017 (UTC)

Support (T156847)

 * 1) Shizhao (talk) 06:55, 6 February 2017 (UTC)
 * 2) --Шухрат Саъдиев (talk) 11:58, 6 February 2017 (UTC)
 * 3) Amir E. Aharoni (talk) 13:48, 6 February 2017 (UTC)
 * 4) Bmansurov (WMF) (talk) 14:26, 6 February 2017 (UTC)
 * 5) BDavis (WMF) (talk) 16:22, 6 February 2017 (UTC)

Problem
Creating new classes/widgets with OOJS UI feels very cumbersome (see T155567: Make OOjs UI easier to use for gadgets). E.g. method declaration is split into different statements all across the source file.

Who would benefit
Any developer that wants to work with OOJS (UI)

Proposed solution
Create a high level function that allows more declarative creation of a class. E.g.:

Problem
By default MediaWiki sends only oldfashioned plain text mails. With Extension:Echo there is at least a way to deliver some kind of HTML mail, but it is still very hard to customize the layout and design of those mails (need to override/extend classes).

Who would benefit
All developers that need to customize notification mails. This is especially a need in business contexts.

Proposed solution
There could be some directory that contains an HTML template and all required resources. E.g  which contains ,  ,  , ... Also the use of a library like SwiftMailer or PHPMailer should be considered.

There has been some approaches in the past, and I believe something like this is already planned for the Outreachy T15303: Implement HTML e-mail support in MediaWiki

Support (T156231)

 * 1) SSethi (WMF) (talk) 04:41, 6 February 2017 (UTC)
 * 2) David1010 (talk) 06:40, 6 February 2017 (UTC)
 * 3) --Шухрат Саъдиев (talk) 12:01, 6 February 2017 (UTC)
 * 4)  ·addshore·  talk to me! 12:18, 6 February 2017 (UTC)

Make it easier to create an OOUI theme
To create a theme currently: get the oojs/ui repo, copy-paste the src/themes/blank directory to your own name, list the new theme in Gruntfile.js and maybe a few other places (i could find them all if you're serious about doing this), and start writing the CSS

I want a more modular approach, where themes are definable in any extension, and consist of an array of variables in json or less or something which OOUI then assembles that into the css/js itself:


 * A set of colours for different things (borders, backgrounds, text, different types of buttons, etc)
 * General properties - how much spacing in general, whether to even use any shadows, whether buttons should be gradiented or flat, whether to override fonts, that sort of thing
 * Specific properties for all the types of things (buttons, dialogs, inputs, etc) such as rounded corners, gradients, shadows, fonts, padding - none, or specific values (what sort of gradient, what sort of shadow, how much padding)
 * Profit?
 * Profit?

Support (T155562)

 * 1) Charlie Kritschmar (WMDE) (talk) 12:17, 6 February 2017 (UTC)
 * 2) Jan Dittrich (WMDE) (talk) 12:41, 6 February 2017 (UTC)

VE support for skins should be done by adding appropriate anchors/ids/styles to the skins, and not by editing VE itself
Apparently the only way to make a skin work with VE is to edit VE itself. This makes it very hard to make new skins compatible with VE, despite more and more third-party projects desiring such compatibility.

It should be the other way around - compatibility should be in the skin, not VE. The skin should be edited to meet VE's expectations (maybe have appropriate ids or whatever on things where it should be showing up around the content, or a js snippet specifying how it is supposed to show up, or whatever?), and modified and styled appropriately to look right with it.

And how to do this should be documented somewhere so we can actually, well, do it.

Remove QUnit CompletenessTest
The CompletenessTest was my attempt at getting a basic code coverage report using run-time inspection instead of static instrumentation.

It was never fully developed, remained somewhat unstable, isn't used by Jenkins or otherwise enabled or encouraged, and its results are not publishable, either. (Only works locally as on the Special:JavaScriptTest HTML view).

The "export" feature for Special:JavaScriptTest introduced in 2014 for Karma and TestSwarm (ba50b3255) lacked support support for loading the CompletenessTest. And when the regular "skinned" mode was deprecated and, eventually, removed last year in 0f9e4ca0f it essentially hasn't been used anymore as far as I can see.

From a Git-wide search I see that various Wikibase repositories still have references to it, so I won't remove it just yet. But it'd be good to know for sure if and how it's being used there. There's no rush behind its removal, but if it's not being used, that I'd rather we remove it from core.

Image

Support (T155194)

 * 1) Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)

Make OOjs UI easier to use for gadgets
As I explained in T155473: Improve documentation of OOjs UI

For example when someone wants to make a dialog box in OOjs UI: (Copied from here).

What I would love to see is some sort of form factory in javascript. Like HTMLFormFactory in php. So we only build an array of form descriptors and call it, then bam! the form is there. Something like:

And/or somerhing like jQuery (which can consume existing HTML s as the source of the dialogue:

Endorsements (T155567)

 * 1) It affected me personally: I tried to develop a gadget and it was hard to find the right documentation. And it will affect many people very soon: The direction of the development is to gradually replace all editing, in rich-text and in source code, with components based on VE, NWE, and OOJS. This is good, but there are hundreds of gadgets written for the old wikitext editors, and without rewriting those gadgets the transition to NWE cannot happen. Amir E. Aharoni (talk) 13:59, 6 February 2017 (UTC)

Support (T155567)

 * 1) Shizhao (talk) 06:57, 6 February 2017 (UTC)
 * 2) Ladsgroup (talk) 10:04, 6 February 2017 (UTC)
 * 3) Tim&#160;Landscheidt 11:37, 6 February 2017 (UTC)
 * 4) Jan Dittrich (WMDE) (talk) 12:41, 6 February 2017 (UTC)
 * 5) Osnard (talk) 12:54, 6 February 2017 (UTC)
 * 6) Amir E. Aharoni (talk) 13:51, 6 February 2017 (UTC)

MediaWiki support for Composer equivalent for JavaScript packages
We should have an equivalent for JavaScript to what we have with Composer for PHP. A simple way to manage dependencies and install required JavaScript modules automatically.

Problem
 * 1) Both core and extensions depend upon 3rd party javascript libraries while we currently lack a system to manage those dependencies
 * 2) Instead, 3rd party libraries get duplicated into—and sometimes across—our repositories.
 * 3) * Creates higher code complexity of our own repositories as 3rd party code—with all its flaws—is effectively part of our own code now
 * 4) * High effort to manually updating those libraries by copy and paste
 * 5) * Some libraries get effectively forked into our repositories while this is not necessary and makes updating/maintaining/reusing them even harder
 * 6) * Conflict between MW coding conventions and the pasted libraries ones

Who will benefit
 * 1) Developers: Development efficiency
 * 2) * More predictable and maintainable code due to reduced code complexity
 * 3) * Less worries about conflicts across different MW extensions and a simple way to share JS code between them
 * 4) Security: Simpler to keep an eye on security issues in 3rd party libraries and to deal with them
 * 5) Possibly, WMF Deployment team.

What we need
 * 1) We need to settle on a system to track 3rd party javascript libraries. Something similar to composer.json or package.json or extension.json
 * 2) We need to implement a way to make the selected system scalable and usable for both end users, developers and WMF deploymen
 * 3) (optional) deduplication of libraries/flattened dependency trees
 * 4) (optional) predictability of versions used of libraries based on 1. (lock files, shrinkwrap).
 * 5) (optional) packaging download and update platform (npmjs etc)

Possible solutions
 * 1) Yarn an NPM compatible client that combines benefits of composer (vendor dir, versioncontract/lock file, package deduplication etc).
 * 2) Plain NPM for external users and developer, And then build a WMF specific  'vendor' concept on top and other things we need. maybe some CDNJS like system perhaps ?
 * 3) Specify a structure for how to import libraries into our extensions (RL flag ?), so that it is more clear what we use, what versions they are etc.
 * 4) Turn JS libraries into composer packages.

Support (T107561)

 * 1) Info-farmer (talk) 05:20, 6 February 2017 (UTC)
 * 2) —Th e DJ (Not WMF) (talk • contribs) 08:57, 6 February 2017 (UTC)
 * 3) Felipe (talk) 13:46, 6 February 2017 (UTC)
 * 4) BDavis (WMF) (talk) 16:23, 6 February 2017 (UTC)

Special:MobileLanguages should be in core and called Special:Languages
The mobile skin minimises payload by not serving languages in the page and instead using JavaScript to load other languages or for those without JavaScript a special page fallback

The parameter given to the page is the page to retrieve languages from. For example: https://en.m.wikipedia.org/wiki/Special:MobileLanguages/San_Francisco

This should be in core in some form so it can be used by other skins.

This is one of many non-standard language selectors which need to be consolidated; see also T73136: Improve language selection.

Support (T104660)

 * 1) Liuxinyu970226 (talk) 08:07, 6 February 2017 (UTC)
 * 2) —Th e DJ (Not WMF) (talk • contribs) 08:56, 6 February 2017 (UTC)
 * 3) Amir E. Aharoni (talk) 14:00, 6 February 2017 (UTC)
 * 4) Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)

Deploy Sentry (JavaScript error logging) to production, configured to log only a limited subset of users/pages
Noticing, tracking and debugging errors should be easy. Wikimedia developers and users should be able to easily notice new errors (possibly only a subset of them that they are interested in), find out details, and share with others. At the same time security and privacy standards should be enforced.

Sentry is the most popular open-source software for error logging and aggregation; we should use it to (initially) collect errors from logged-in users (maybe leaving out the largest wikis, if the high traffic is problematic - those wikis are usually better at noticing problems quickly anyway) and/or errors on some specific pages with smaller traffic and more problematic history (e.g. Special:UploadWizard).

Endorsements (T91649)

 * 1) JavaScript errors in local gadget, user scripts, and Common.js customization is one of the most frequent causes of trouble in smaller wikis. It even happened in the Japanese Wikipedia, which is a top-ten Wikipedia—several features were quietly broken for weeks for hundreds of editors because of an error in a gadget, and it was only by a developer who could fix it thanks to a user who complained about a broken feature. There should be more proactive monitoring for this. Amir E. Aharoni (talk) 14:02, 6 February 2017 (UTC)

Support (T91649)

 * 1) Amir E. Aharoni (talk) 14:00, 6 February 2017 (UTC)
 * 2) BDavis (WMF) (talk) 16:24, 6 February 2017 (UTC)

Set $wgLegacyJavaScriptGlobals = false by default
Per ResourceLoader Migration guide, there are plans to set $wgLegacyJavaScriptGlobals to false and remove the global JavaScript variables (such as ).

I'm opening this bug (similar to T35836: Set $wgIncludeLegacyJavaScript = false by default ) mostly for tracking the progress on this regard.

If anyone knows if this is already scheduled to be done in some specific future version of MediaWiki, please inform us below.

See Also:
 * T72366: Set $wgLegacyJavaScriptGlobals = false on ptwiki and ptwikibooks

Support (T35837)

 * 1) Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)

A cached server-side HTML template should update when you change a partial template which it includes
https://gerrit.wikimedia.org/r/#/c/223165/ has a top-level template  that includes the partial template   using.

I notice on my local wiki if I edit  and view a page with the skin, I see the change to it (good!), but if I edit the partial , I don't see the change to it, even if I use ?action=purge (bug!).

Looking at  in core, it does a simple this doesn't notice changes to partials included by $filename.

(This is probably hard to fix. A workaround is to make cosmetic changes to all parent templates that include the edited partial template. The bug and workaround is documented in https://www.mediawiki.org/wiki/Manual:HTML_templates#Caching.)

Support (T113095)

 * 1) —Th e DJ (Not WMF) (talk • contribs) 08:58, 6 February 2017 (UTC)
 * 2) Bmansurov (WMF) (talk) 14:28, 6 February 2017 (UTC)

Dismantle ResourceLoader's "targets" system
Endlessly discussed and griped about but apparently there's no task.

This system is carelessly leaving behind a trail of maintenance overhead. With new issues popping up all the time. Here's a quick sample just from MediaWiki core (quick Resources.php search for "target" and "mobile").


 * rMWc2d117b379ef: Add mobile target to modules needed for mw.msg
 * rMWa4fcb5914034: make jquery.json module run on mobile
 * rMW69d779cf3521: Add mobile target to QUnit and its dependencies
 * rMW50f46c678ef0: Add mobile target to jquery.getAttrs
 * rMW007acdc32b0d: Add an explicit targets declaration for mediawiki.inspect & $.byteLength
 * rMW4726a3081a1e: Add mobile as a target on VisualEditor dependencies.
 * rMW2947ba0244fc: Use Agora oojs-ui theme on mobile
 * rMWe0897187b826: Resources: Enable es5-shim and json for mobile as well as desktop target
 * rMWecc5f63a8401: Fix mediawiki.ui.checkbox loading in mobile
 * rMW21ec580f0665: Load mediawiki.action.view.redirectToFragment in mobile
 * rMW017242816293: Allow mediawiki.cookie module to be used on mobile
 * rMW81c11be76e41: Allow mobile for jquery.throttle-debounce
 * rMWde0c7cb1c180: Allow usage of mediawiki.api.options on mobile
 * rMWfce27ff32857: Add mobile target for mediawiki.confirmCloseWindow
 * rMW67c1308ceeaa: Adding mobile target to mediawiki.template.mustache
 * rMW945eabb7883c: Add target mobile to jquery.textSelection
 * rMWe81b4e46a075: mediawiki.ForeignApi: Module should target mobile
 * rMWb41781f08ea1: Add 'mobile' target to 'mediawiki.raggett' module
 * rMW639cecb4bec8: Allow UserInputWidget on mobile


 * T66512: &#91;Regression&#93; mediawiki.util broken under target=mobile (unknown dependency jquery.accessKeyLabel)
 * rMW80f1f08272ad: jquery.accessKeyLabel: Enable for target=mobile
 * T67823: VisualEditor: &#91;Regression pre-wmf7&#93; Mobile VE doesn't load due to dependency on mediawiki.skinning.content.parsoid which is not available for mobile target
 * rMW9cf7b5fee10f: Enable mediawiki.skinning.content.parsoid on Mobile target too
 * T78069: JS is broken on mobile web
 * rMW96180a49179b: Allow moment on mobile web
 * T93262: MobileFrontend doesn't do URL updating for redirects
 * rMWf6bda94623d0: Enable mediawiki.action.view.redirect on mobile
 * T104940: Mobileview complains about "Uncaught Error: Unknown dependency: mediawiki.api.parse"
 * rMW92592631ecb3: mediawiki.api: Include 'mobile' target in mediawiki.api.parse module
 * T108191: Mobile site not functional - Uncaught Error: Unknown dependency: mediawiki.legacy.wikibits
 * rMW0dadc3972be2: Add 'targets=desktop,mobile' to mediawiki.legacy.wikibits module
 * T63861: VisualEditor: Show something other than a blank page when editing a redirect page
 * rMW848eabef42e9: Make mediawiki.action.view.redirectPage available on mobile
 * T126935: Redirects are not italicized on mobile Special:PrefixIndex/User:... page
 * rMW46cabd425225: Add mobile target to mediawiki.special

Support (T127268)

 * 1) ThurnerRupert (talk) 12:06, 6 February 2017 (UTC)
 * 2) Felipe (talk) 13:47, 6 February 2017 (UTC)
 * 3) Amir E. Aharoni (talk) 14:03, 6 February 2017 (UTC)
 * 4) Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)

[jsduck] Various custom tags should be easily shareable between projects
Recently we introduced the jsduck see tag in MobileFrontend, which isn't part of the vanilla jsduck. Actually we need to add a customTag our self to use it without warnings from jsduck. The feature request for jsduck isn't implemented at the moment and there is no roadmap for it (as i can see).

VisualEditor itself (like mentioned by Krinkle on the feature request) uses a set of custom tags and there are other projects using this (and other) custom tag(s), too (core, VE and GuidedTours). It would be possible to use cores CustomTags.rb in jsduck, but with it it wouldn't be easy to share custom tags introduced in VE or MF, e.g.. So it would be great to have a central repository (e.g. a git project in gerrit) to manage tags used in wmf projects to simply clone it (maybe integrate it as a submodule) into the project (or a seperate directory) and use it. An update of a tag or new tags could be used without any problems by updating the local copy of the repo.

Support (T86587)

 * 1) David1010 (talk) 06:42, 6 February 2017 (UTC)
 * 2) Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)

meta=siteinfo should allow client to identify RTL languages
https://en.m.wikipedia.org/w/api.php?action=query&format=jsonfm&meta=siteinfo&siprop=general%7Clanguages&prop=langlinks&llurl=true&lllimit=max&titles=Tofu

This returns language names and article titles in many languages (which is used to construct a language switcher interface on the mobile web interface). To do that properly, mobile we need to identify which languages are RTL and which are not.

Expected: Return an  property when a language is RTL.

Support (T74153)

 * 1) Liuxinyu970226 (talk) 08:08, 6 February 2017 (UTC)
 * 2) Amir E. Aharoni (talk) 14:03, 6 February 2017 (UTC)

Support a responsive grid system
In order to consistently accommodate multiple screen sizes we need a responsive grid system.

We had an RFC and an initial implementation that needs some polishing. Additional work may be needed to make sure it works well with OOjs-UI components.

Support (T90687)

 * 1) Shizhao (talk) 06:59, 6 February 2017 (UTC)
 * 2) —Th e DJ (Not WMF) (talk • contribs) 09:00, 6 February 2017 (UTC)
 * 3) RHo (WMF) (talk) 11:35, 6 February 2017 (UTC)
 * 4) ThurnerRupert (talk) 12:05, 6 February 2017 (UTC)
 * 5) Osnard (talk) 12:55, 6 February 2017 (UTC)
 * 6) NKohli (WMF) (talk) 13:24, 6 February 2017 (UTC)
 * 7) Amir E. Aharoni (talk) 14:03, 6 February 2017 (UTC)
 * 8) BDavis (WMF) (talk) 16:25, 6 February 2017 (UTC)
 * 9) EBernhardson (WMF) (talk) 18:01, 6 February 2017 (UTC)