As a useful utility function, we've copied this method several times
across multiple extensions, which is a pretty good sign it should
actually live in core.
Changes:
* Add `mediawiki.viewport` module
* Rewrite method to be more robust and accept any viewport
* Add `mw.viewport` to jsduck categories file
* Add method for checking if an element is close to the viewport
* Add unit tests
Bug: T124317
Change-Id: I38eec4f1e568f51e7e212b2b3f10b8da8d36f316
* Add template partial support which matches the server-side implementation
and means that we have full mustache support.
https://mustache.github.io/mustache.5.html#Partials
Bug: T97188
Change-Id: Ic752f52669dbffa21c4a514509c3ea1da8ac5d9c
We often use the idiom "window.onload" or "$(window).on('load')".
Since code loads asynchronous, this is problematic because the event won't
always be observed as it may fire before the event handler is attached.
Most tasks also don't really want to wait until the page is loaded (in which
case it would run immediately if the page is already loaded). Rather their intent
is just to defer it to a later point in time – to avoid disrupting user events.
Bug: T111456
Change-Id: Ieba0440c6d83086762c777dfbbc167f1c314a751
* Move tests to a separate test suite.
* Unit tests already covered these cases without second and third
parameter so no extra tests.
* Update code to clearly make attribs optional.
Bug: T88962
Change-Id: I26bb4b0a907f48064f41236972e115ec1f7edf0c
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
