These classes will be used to send uploads from one wiki to another,
and the latter includes (partial) adherence to the Commons structured
data system [0].
[0] https://commons.wikimedia.org/wiki/Commons:Structured_data
Change-Id: I96fcb862eb854d23b6f9f553a87fa7ca65bf5a93
Bug: T105071
The module provides a generic bucketing function - it accepts an
experiment specification and a token that identifies a unique user - and
doesn't have any side effects, i.e. the bucket isn't persisted to
storage. It is therefore assumed that clients are responsible for either
storing the token or storing the bucket for the duration of an
experiment.
The module was extracted from the - admittedly, unused - module of the
same name in the MobileFrontend extension as it's intended to be used by
the Gather and QuickSurveys extensions.
Bug: T109010
Change-Id: Icf7f6fedf0c2deb5d5548c9e24456cc7a7c6a743
mw.ForeignApi is an extension of mw.Api, automatically handling
everything required to communicate with another MediaWiki wiki via
cross-origin requests (CORS).
Authentication-related MediaWiki extensions may extend it further to
ensure that the user authenticated on the current wiki will be
automatically authenticated on the foreign one. A CentralAuth
implementation is provided in I0fd05ef8b9c9db0fdb59c6cb248f364259f80456.
Bug: T66636
Change-Id: Ic20b9682d28633baa87d22e6e9fb71ce507da58d
Provide a standard mechanism for accessing localStorage.
It may seems simplistic right now, but to give an idea of the why:
* We already have jquery.jStorage.js which is a much more heavyweight
approach to storing non-essential values.
* We are repeating ourselves a lot in extensions by having
to do localStorage detection and then deal with full localStorage.
In MobileFrontend we have a settings module. This is one of the reasons Gather
depends on MobileFrontend and I'm keen to remove that dependency.
* We might want to move to indexdb in future. Having a single API makes moving
this easier - we don't have to update everywhere that uses localStorage
* Saving non-string support would be useful. The API could be adjusted to take a
mixed second parameter that stringifys JSON objects.
* Cookie fallbacks are a possible alternative when localStorage is not supported. This allows
us to be agnostic of the storage mechanism going forward.
Note:
This doesn't reuse the handling in mediawiki.js as at this point
I am not sure there is value. mw.loader.store.enabled is false when
$wgResourceLoaderStorageEnabled is not true and this should work even
without that case. We can review this at a latter point.
See:
Id5c32bb7a662dda8d153490f7c47e972cabc1efd
I3fd44b0ae6633a7053aee247bc3c4704ba987bc8
Bug: T96155
Change-Id: Idb37352acecd745beb53aa8d77ea050851448e0d
Updating all non-third-party scripts to depend on 'dom-level2-shim'
and use the constants.
* jquery.highlightText
* jquery.tablesorter
* mediawiki.api.upload
* test.mediawiki.qunit.testrunner
Change-Id: Ib07dded9fa18c749b3c064ab90326852146567b2
The core implementation will only support wikitext.
Flow will add its own implementation, and it can be used for any talk
page system identifiable by content model.
Bug: T91805
Change-Id: Ic69acafb24aa737536fe3a074e1958690732f0a7
Adds a global error handler that sends errors to mw.track as
an errorLogging.windowOnerror event.
Bug: T88874
Change-Id: Ic091c9f93c59bda47bda2cfd609c64cd1d014b39
Implemented mw.Api#saveOptions to save user preferences.
If necessary, the options will be saved using several parallel API
requests. Only one promise is returned that resolves when all requests
are complete.
If a value of `null` is provided, the given option will be to reset to
the default value.
Any warnings returned by the API, including warnings about invalid
option names or values, are currently ignored. This basically means
that all requests will succeed (barring networks problems, internal
server errors and such).
Change-Id: Ia015898ca910923e00bc53f099b4e5631d6ad45c
The jQuery Client library is no longer mastered in MediaWiki, and is
instead a proper, published library, which is now tagged as v1.0.0.
Change-Id: Idd19d738b392a5f742fef6f98c885e8c391a5cbf
The sorting is dependent on how the values in the cells are recognized
and translated into sortkeys. We have a limited set of testcases on
full tables, but I wanted to get a better grip on what these parsers
are capable of and of their correctness on their output data.
Currently all tests are succeeding and documenting current behavior,
some of which might arguably be incorrect.
Change-Id: I2dc551c5905431e7d4e6d4373144092449bdcd4d
Add an 'export' subpage to SpecialJavaScriptTest which allows
one to request a self-sufficient JavaScript payload that will
bootstrap a ResourceLoader client and load the test suites.
This is needed for using Karma (which only loads JavaScript,
no full html pages). As such elements from the Skin and OutputPage
will not exist. While all QUnit tests in MediaWiki core and
most extensions I've seen already use #qunit-fixture, this is
now required. This to prevent leakage of elements from one
test to another, but it also prevents tests from depending
on elements provided by the server.
While the Karma setup is still in the pipeline (might land before
this commit loses WIP status), for now this can be tested via
the 'Special:JavaScriptTest/qunit/plain' subpage.
Refactor:
* Use HTTP status code 404 in the response for "noframework".
* Simplify HTML footprint by using <div id="qunit"> instead of
hardcoding the full structure. This feature was added to QUnit
since v1.3.0 (Feb 2012), we're using v1.14.0 (Jan 2014).
QUnit's header is automatically derived from document.title.
* Remove redundant addModules() for 'test.mediawiki.qunit.testrunner'.
This is already added by default.
* Move allowClickjacking() call so that it applies to other modes
as well. The exported javascript needs to have wgBreakFrame set
to false so that test runners can frame it.
* Change mediawiki.special.javaScriptTest to not depend on QUnit.
It caused QUnit to load on error pages. And in theory the page
is suited for other frameworks and shouldn't load QUnit this way.
Bug: T74063
Change-Id: I3d4d0df43bb426d9579eb0349b8b5477281a7cfc
A base ResourceLoaderModule::getTemplates() exists for subclasses
to override. An implementation is provided for ResourceLoaderFileModule.
For file modules, templates can be specified in the following manner:
'example' => array(
'templates' => array(
'bar' => 'templates/foo.html',
),
'scripts' => 'example.js',
),
The delivery system is template language agnostic, and currently
only supports "compiling" plain HTML templates.
This also adds template support to the following modules as a POC:
* mediawiki.feedback
* mediawiki.action.view.postEdit
* mediawiki.special.upload
Works with $wgResourceLoaderStorageEnabled
Change-Id: Ia0c5c8ec960aa6dff12c9626cee41ae9a3286b76
Not ready for merging, and Roan says that the +2 was
most likely accidental and meant to be a -1.
This reverts commit d146934f94.
Change-Id: I3926c9ae9e3c8026fceb3aeedd3b1f1d9b91667b
Preparation work for templating in core.
RL should allow us to ship HTML / template markup from server to client.
Use in Special:Upload and mediawiki.feedback as a proof of concept.
Separation of concerns etc...
See Also:
Ia63d6b6868f23a773e4a41daa0036d4bf2cd6724
Change-Id: I6ff38c12897e3164969a1090449e626001926c3b
Provides functonality similar to WebRequest#getCookie and WebResponse#setcookie.
Wraps $.cookie and automatically takes care of wgCookiePrefix etc.
Bug: 49156
Change-Id: I217ef258aecf1acd335e2cea56ae08b22541c7d4
Co-Author: Matthew Flaschen <mflaschen@wikimedia.org>
Co-Author: Timo Tijhof <krinklemail@gmail.com>
`mw.Title#getNameText()` strips anything following a dot (.), assuming
it's a file name (which doesn't make sense for category names).
C.f. https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Title-method-getMainText
This causes some trouble in UploadWizard's category-suggestion system.
This bug has been there since the very first version (cb0cf72eba)
which, ironically, was specifically written for UploadWizard.
Bug: 64764
Change-Id: I2925e1050215272cdf03c8c6b1de6ba79348f6a5
Extracted the accessKey logic from mediawiki.util and moved it to it's
own module. mediawiki.util now depends on the new module,
moved the jquery.client dependency from mediawiki.util to the new
module.
Now the accesskey is also set, when no placeholder like '[x]' is set on
the title (bug 48505).
Also the label for a input or textarea (and some other elements) gets
updated (bug 63849).
Also implements support for the browsers accessKeyLabel function (bug
37239), which will give a localised accessKey string, if supported (at
the moment FireFox 8+ only)
Bug: 37239
Bug: 48505
Bug: 63849
Change-Id: I211593629ca23540dcd5a93b11834155f4f04883
* Remove dependency from mediawiki.util to mediawiki.toc.
* Load module mediawiki.toc only when toc is existent.
Gadgets that use the messages "showtoc" or "hidetoc" should explicitly
load the module mediawiki.toc or use their own messages.
Follows-up I3ca2acb70db98d00e3f1b (implements mediawiki.toc).
Change-Id: If0438b7b6f4649434e2b83133d6f583f2f8eff16
* Instead handle it client side, and not as a deprecated feature.
* Rename 'page' parameter to 'pages'.
* Add unit tests.
Change-Id: I81ec4282aedd91e3f0bb2ed0d6dd34e437b54f5d
The ie fixes file assumes running in the global scope. Since it
runs locally in our environment, it ends up destroying its
references to e.g. the Date object.
Then when calling sandbox.useFakeTimers, the Date constructor
will yield an object with no methods and tests will fail at a
random point when e.g. trying to access date.getTime().
* Remove 'clock' from the sinon properties we inject into the
test context. We use the sandbox instead (just like for server).
This also fixes a shadow clash with the tests that stored the
clock instance in `this.clock`.
Change-Id: I6085bccf5038e4751da48ee765fe81560f58c6e8
Fix two issues which caused jquery.color to be incompatible with
the currently used jQuery version:
* The $.fx.step hook in jquery.color.js relied on fx.state which is
not provided by current jQuery. This commit replaces it with
a manual flag (the same logic is used in the official jquery.color
plugin).
* It used $.curCSS which has been replaced by $.css.
Change-Id: I3aa0d912b21da40167124c646fb1b35beb277a33
To be used in mediawiki.api tests and elsewhere.
For now they are opt-in and disabled by default,
individual tests can enable fake timers, servers and/or
xhrs by calling this.sandbox to access the dedicated
sinon sandbox for that test.
Clock example:
QUnit.test( 'example', function ( assert ) {
var clock = this.sandbox.useFakeTimers();
setTimeout( function () {
assert.ok( true, 'test' );
} );
clock.tick(1);
} );
Server example:
QUnit.test( 'example', function ( assert ) {
this.server = this.sandbox.useFakeServer();
new mw.Api().getToken( 'foo' ).done( function ( token ) {
assert.equal( token, '0123abc', 'Token' );
} );
// assert.equal( this.server.requests.length, 1, 'Requests' );
this.server.respond( function ( request ) {
request.respond( 200, { 'Content-Type': 'application/json' },
'{ "tokens": { "testactiontoken": "0123abc" } }'
);
} );
} );
Change-Id: I789fb71903f26dbbfe781f010dc5cd3756759943
These modules should only be loaded when $wgEnableJavaScriptTest
is true. Move these modules to the registry that is only activated
in that context and rename the modules to be namespaced under 'test.'
so that there is no mistake when referencing these that they are
not regularly available.
Change-Id: I21e69f50b006904b12fe9f79c196c903ebff4661
* New file mediawiki.toc.js without global function.
* Keep minimal function mediaWiki.util.toggleToc() for compatibility.
* Mark mediaWiki.util.toggleToc() as deprecated.
* Adapt mediawiki.util.test.js.
* Add new file mediawiki.toc.test.js.
* Solves bug 60030 and allow multiple toc.
Bug: 60030
Change-Id: I3ca2acb70db98d00e3f1bd2227091bd32d8e18a5
This is a fork from Mathias Bynens' jquery.placeholder as of this commit
47f05d400e/jquery.placeholder.js
New features added:
* Support for valHooks and propHooks
* Clearing placeholders upon for submission
* jquery.placeholder QUnit test suite
Bug: 57179
Change-Id: I1ecca3d89bb964414ad8765caaa7e1958b94f762
For now it just verifies that the very basic synchronous functionality
of the module works; not much more is possible without triggering some
events to hook to, and currently jquery.makeCollapsible doesn't
trigger any.
Change-Id: Icdd8f392e4921007a6bdfb3ae934949e4c875232
Jenkins tests for extensions were exiting with a false positive.
They were marked "success" but in fact were wrong because
it only ran the core tests, the extensions' test suite was
loaded after QUnit already stopped listening.
Change-Id: I164d60e06118b64a1c6a17665a0fb1faeff744e5
* adds $wgResponsiveImages setting, defaulting to true, to enable the feature
* adds 'srcset' attribute with 1.5x and 2x URLs to image links and image thumbs
* adds jquery.hidpi plugin to check pixel density and implement partial 'srcset' polyfill
** $.devicePixelRatio() returns window.devicePixelRatio, with compat fallback for IE 10
** $().hidpi() performs a 'srcset' polyfill for browsers with no native 'srcset' support
* adds mediawiki.hidpi RL script to trigger hidpi loads after main images load
Note that this is a work in progress. There will be places where this doesn't yet work which output their imgs differently. If moving from a low to high-DPI screen on a MacBook Pro Retina display, you won't see images load until you reload.
Confirmed basic images and thumbs in wikitext appear to work in Safari 6, Chrome 21, Firefox 18 nightly on MacBook Pro Retina display, and IE 10 in Windows 8 at 150% zoom, 200% zoom, and 140% and 180%-ratio Metro tablet sizes.
Internally this is still a bit of a hack; Linker::makeImageLink and Linker::makeThumbLink explicitly ask for 1.5x and 2x scaled versions and insert their URLs, if different, into the original thumbnail object which (in default handler) outputs the srcset. This means that a number of places that handle images differently won't see the higher-resolution versions, such as <gallery> and the large thumbnail on the File: description page.
At some point we may wish to redo some of how the MediaHandler stuff works so that requesting a single thumbnail automatically produces the extra sizes in all circumstances. We might also consider outputting a 'srcset' or multiple src sizes in 'imageinfo' API requests, which would make ApiForeignRepo/InstantCommons more efficient. (Currently it has to make three requests for each image to get the three sizes.)
Change-Id: Id80ebd07a1a9f401a2c2bfeb21aae987e5aa863b
Updated script for generating mediawiki.jqueryMsg sample
data to be generic instead of Jasmine specific
Removed mediawiki.jqueryMsg.spec.js
* The bulk of the tests were already in QUnit (did that a
while ago)
* The little $.each loop over the sample data is now in
QUnit as well.
* Made it so that it doesn't need a hardcoded copy of
languageClasses but instead pulls it from load.php
on-demand and then restores mw.language later on.
The mediawiki.jqueryMsg.test module now has several failures
which is annoying but should not block the merge for now
because they were failing under Jasmine as well, this is a
known bug in jqueryMsg, a few cases don't work in js yet.
To be investigated (12/66 fail currently).
Change-Id: I243d055d6f5129fd9fd760943d05c7cd210d84bf
The JavaScript code of the parser was written by Santhosh.
The original project is hosted at GitHub:
https://github.com/santhoshtr/CLDRPluralRuleParser
Introduces resourceloader modules: mediawiki.cldr and
mediawiki.libs.pluralruleparser.
hi.js and ar.js removed since it has only convertPlural method. More [lang].js
needs to remove convertPlural, but not done in this commit.
The actual rules will be taken straight from CLDR and they are not
integrated in this commit yet.
Change-Id: I1aa3b081f4dad68515fd6cd46e4ab2dbdb3291eb
- Deprecates 'ok'/'err' properties.
They still work, but are no longer mandatory.
Instead the Promise interface should used.
- See unit tests for good examples of how it works.
http://alpha.dev/mediawiki/core/wiki/Special:JavaScriptTest/qunit?module=mediawiki.api
- Migrated submodule "mediawiki.api.parse" as example.
Other mediawiki.api.* submodules will be migrated later.
Change-Id: I4d8428124598093f220dd28a8cbf861686ab61a7
The language specific tests will be executed for the user language
(see also bug 37321).
Splitted from I4f3c7da84c4794fbe7bcbef52cfd49b1b7a3a521
Change-Id: I9b1c991d00f4af1d8ee409f65f123a006f0eb443
