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
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
