Follows-up 3801e54c29.
Also:
* Split the test into smaller more dedicated tests.
* Make minor changes so as to only assert values in the tests'
outer scope. Assertions within callbacks are an anti-pattern
that is fragile and can easily miss or mask problems. Using a
single state observer that is modified by the callbacks makes
for strict assertions with no implied or untested behaviour.
Callbacks running in a different order or a different number of
times now cause assertion failures - instead of causing the
assertion to not be run, or to be run multiple times, which
would pass.
Bug: T192623
Change-Id: Ice1560b754f8df29ca583eea19f559020fafaf12
These are all quite tiny and not worth providing separately
to the system as deliverable file bundles.
Mark the other mediawiki.api.* modules as alias to 'mediawiki.api'
for back-compat, with deprecation warning.
Highlights:
* Change mediawiki.api.edit.js to not use mw.user, because that
causes a circular dependency, given mw.user also depends on
mediawiki.api.
Bug: T192623
Change-Id: I0afdc8ab50bc1354bb5099bf39923c07eab0b665
In change Ia1269fd898dabbcf1582618eab46cef97e10a3b1 I want to add
functions that deal with codepoints instead of bytes to these modules,
after which the names wouldn't make sense. Doing this in a separate
commit to make the diffs clearer.
Change-Id: Ia554eb2265248e72b04fce69a662a9db1a5f1275
These methods do not belong on the jQuery object. And to resolve
T185948, we need to also add codePointLength and trimCodePointLength,
and this new module seems like a good place to put them.
There is no `mw.String` global, this module has to be used via `require()`.
Deprecations:
* Function `$.byteLength` (from module 'jquery.byteLength') is
deprecated, use `require( 'mediawiki.String' ).byteLength` instead.
* Function `$.trimByteLength` (from module 'jquery.byteLimit') is
deprecated, use `require( 'mediawiki.String' ).trimByteLength` instead.
* Module 'jquery.byteLength' is deprecated, use 'mediawiki.String' instead.
Note that `$.fn.byteLimit` and the 'jquery.byteLimit' module are not
deprecated.
Change-Id: I2501a79efee644e5f4a9f5c977fe49c8c05c6eb3
This parameter is a no-op for these tests, as such, nothing was being
tested by specifying it in tests. The behaviour 'test' and 'test.top'
was identical.
Bug: T184257
Change-Id: Ia2bb731f00d4b4175f7b75174aeafaca9412329e
On supported browsers handle the auto hide timeout with a
count of cumulative time the page has been visible to the
user. Old functionality can still be accessed, if desired,
by setting the visibleTimeout notification option to false.
On browsers without support for this visibilitychange event
wall clock time (the old behaviour) is used.
Adds a library function functionally similar to setTimeout that
only considers time when the page is visible. This is useful
both for analytics purposes, and when you want to temporarily
put something on screen and be reasonably certain it doesn't
go away until a user has seen it.
Bug: T42322
Change-Id: I7d8ea85602cae9cfc72e0155bc3092049ecafd43
This will allow us to load them in the backend, and to keep
consistency between RecentChanges and Watchlist if needed.
Added also a 'backup' preference to keep the previous version
before the conversion, in case of mangling of the queries.
Bug: T166908
Change-Id: I8e26b66e43bd16282b7bdb52abc152f92a9c877d
* Deprecated since MediaWiki 1.26.
* Not used anywhere in Wikimedia Git.
* Grafana mw-js-deprecate dashboard shows < 1 hit per day on average
for any of the jquery.mwExtension properties, during the past 3 weeks.
Most days 0, some days 18 individual hits.
By comparison, legacy wikibits before we removed it in May 2017 was down
to about 6,000/24h (combined), so removal is quite overdue.
Change-Id: Ib66d1844b4fb8d7185b0e6607b9f98c1be632bb5
The backend always merges the query with wiki/user defaults before
it gives us data. The frontend, though, initially assumed that the
state is given strictly by the URL parameters (especially after the
URL shorening commit). This made it so that the frontend state is
incompatible with backend state.
However, always merging frontend state with user/wiki defaults can
produce inconsistencies between URLs in the same wiki, preventing
users from sharing them -- and making it potentially break if ever
a wiki default changes.
The solution is to add 'urlversion=2' to all RCFilters-generated
URLs and have the backend recognize this parameter as 'do not
merge with defaults'.
When RCFilters frontend loads, it checks whether the parameter
exists; if it doesn't, it merges whatever it sees with the defaults
just like the backend, then it transforms the URL to represent the
correct full state, and adds 'urlversion=2' to the URL parameters,
making it consistent across accounts and through time for the
next time it will load.
This means several new behaviors over the 'short url' commit:
- Accessing Special:RecentChanges directly (no query) will result
in one of two things:
-- If there is a saved query that's set to default:
The system will load that saved query "straight forward" (as
if the user clicked that option from the menu) causing, also,
an ajax re-request from the server (since the server does not
yet know about saved queries or their potential for being
the default state.)
-- If there is no saved query default: The system will load
user/wiki defaults (like the backend does) and then fix the
url to represent this state fully (with parameters showing the
actual state of the filters.
-- Both cases will also result in adding 'urlversion=2' to
the end result URL.
- Accessing Special:RecentChanges?urlversion=2 (without any other
parameters) will result in loading a completely empty filter set
in RCFilters. We assume that 'urlversion=2' does not load defaults
even if it is the only parameter in the URL.
- Accessing Special:RecentChanges?hideX=1 (parameter set without
urlversion=2) will result in the front end taking the requested
parameters, merging them with user/wiki default (reproducing what
the backend does) and then adding urlversion=2 to the URL.
In all cases except for the default-saved-query-load case, the initial
load will **not** re-request data from the backend. The backend needs
to adjust to respect urlversion=2 as well (will come in an upcoming
commit) so the state and expectation of both the front- and back-end
are the same.
This commit also factors out URL handing to a separate class (UriProcessor)
and adds unit tests for it.
Bug: T166907
Bug: T166972
Bug: T166974
Change-Id: I0eed3bc0d4fa4810b6301b535c75b6bfbc8b4a5b
It's not very useful and needlessly emits deprecation warnings
which unfortunately cannot be surpressed at runtime.
The test just asserts that a no-op function exists.
Change-Id: I2768ba40191a3c0cc7be6202ffa5bed529eabfee
In practice, this means nothing, as the main browsers affected
were Internet Explorer 8 and early versions of Android (before
1.6), which are already Grade C.
Change-Id: I4488402686c8b9fefa0af5fed3c9a4b83cbff798
Create 'dm' / 'ui' and 'controller' modules for ResourceLoader,
make sure that Special:RecentChanges loads 'ui' module (that
depends on the other two) and yet the qunit tests only load
the dm module.
Bug: T156532
Change-Id: If53a735458703f0bd2c094349edf86f38f05ccd7
Add a new filter experience to Special:RecentChanges with
a drop-down filter menu. Put it behind the rcenhancedfilters
preference, which is hidden for now.
Bug: T149435
Bug: T149452
Bug: T144448
Change-Id: Ic545ff1462998b610d7edae59472ecce2e7d51ea
Doing edits "The Right Way" is non-trivial due there being mulitple strict options that
need to be known and enabled. By default, the API encourages bad behaviour:
* Edit is unexpectedly saved as anon after session becomes invalid.
* Other edits are silently overwritten.
* Accidentally re-creates a deleted page.
* Accidentally creates a new page when an edit was intended (eg. if title was wrong).
Implement abstraction methods for edit and create that handle all this.
Thus guarding JS edits with the same protections as EditPage.
Change-Id: Ic6a35902cbae262971c704b9b8127e54733dac79
* Send 'module' and 'require' parameters to module closures.
This depends on Ia925844cc22f143 being deployed one cycle earlier.
* Patch Moment and OOjs to ensure these libraries continue to expose
their module as globals as well. AMD/UMD-compatible libraries
only expose a global *OR* an export, not both. We need both
for back-compat.
* Update pluralRuleParser to make use of module export to allow
usage via require().
To test, check out the patch and run:
> mw.loader.load('moment');
> mw.loader.require('moment')()
> mw.loader.require('moment')('2011-04-01').fromNow()
Bug: T108655
Change-Id: Idbd054880ee70d659ec760aef8fcb38d0704a394
No major changes for us other than a bugfix that makes the
following work as expected:
var clock = this.sandbox.useFakeTimers();
setTimeout(function () {
clock.tick(10);
});
click.tick(1);
// Expected: 11ms is recorded
// Actual: 1ms is record
This was broken up until Sinon 1.16.0 (Lolex 1.3.0) because it saved the
"clock.now" value before running any pending timeout callbacks. Then it
unconditionally assigned the "clock.now" value to 'oldNow + ticked', which
discarded ticks made by a callback.
Change-Id: I2775f4c6353aef12ced6dc45e73fe8d4e49c2b68
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
