The new module retains the name .ui name so that existing
skin style overrides continue to work. We can consider renaming it
to just "mediawiki.rcfilters.filters" in a future patch.
This does not handle file reorganization, since both of the
modules used package files - instead, in the main script we also
require() the old main script for the .dm module so that its
setup code runs. But, we did need to rename the virtual
config file from the .dm module to not clash with the
virtual config file from the .ui module, since the
latter uses a callback instead of retrieving configuration
variables directly. These can be merged later as well.
Bug: T256836
Change-Id: I5ec0af8b8e6bcdba6b7881f946f777b854a33739
The new functions `lcFirst` and `ucFirst` lowercases/uppercases the
first character of a JavaScript string with support of UTF-16
surrogates for characters out of the Unicode BMP.
Use these new functions at jqueryMsg.
Change-Id: I007b63bfbcc9e4bc7e89f48df9687111bc4db715
No longer in use as of MediaWiki 1.23.
Removed tests that were checking the legacy style, and fixed tests
that were meant to be checking the new style but where making
use of the legacy one.
Bug: T291300
Change-Id: I9692141d9c34a1d4f756d9cfd694651d683d5bc2
- Add Skin::getOptions and Skin::getPortletLinkOptions, which are used
to provide skin options to mw.util.
- Add SkinFactory::getSkinOptions, which is used by
Skin::getPortletLinkOptions.
Depends-On: Ib23360e3439abc828404c1de8e0906915ee7d8b6
Bug: T289163
Change-Id: I801e7d583cb0b0c7da51f4da503268be736bb60c
Unicode characters out of the BMP (starting at U+10000) have in a
JavaScript string two UTF-16 surrogates.
On uppercase of the first character of a title this must be supported.
This change also adds test cases to verify this.
Bug: T291321
Change-Id: I88c4ddbd39000aa09455f67ca8435ce704b98bf8
* Move to separate file.
* Remove most of the verbose assert messages in favour of just
a few words that label the asserted value or the call that it
checks the value of. The actual/expected values are already in
the UI, and the class/method are already in the formatted test
name (which includes the module name).
Change-Id: I43ec038abd0946a92f222a859807e252696c33d4
The tests now work regardless of whether the underlying wiki or browser
would normally have the store enabled (via
wgResourceLoaderStorageEnabled, or in Firefox, or in debug mode).
Bug: T245693
Change-Id: Ib1f8867ae7ba585b7efd11e1a8692fa7da16eb28
== Backgrond ==
When working on an unrelated patch (Ib1f8867ae7ba585b), the tests for
mw.loader.store failed both locally and in CI, consistently, claiming
that the mw.inspect() size for this test case was now 371 instead of
372. It still passed on master where it adds up as 372.
How can this be? Well. Our tests don't run in debug mode, which means
the test suite code is minified. That shouldn't make a difference in
terms of how the code works since all statements, data, and function
calls perform the same either way. And indeed, the part of mw.inspect
that serializes arrays and objects, was unaffected.
It doesn't matter if `x = [ 'a', 'b' ]` or `x=['a','b']`. The data
seen at run-time is identical in every observable way. And thus it is
fully in the hands of mw.inspect() to choose how to measure its size
(e.g. it could call JSON.stringify with or without indentation, but
either way it's going to be consistent and unaffected by how the JS
code was formatted when the array is defined).
But.. it's different for functions. When we measure the size of a
function, we ask the JS engine to reflect back to use the source code
via Function#toString. This exposes details of minification. That's
still okay, in that the expected size of 372 is the size with this
minification taken into account.
== The problem ==
A good minifier should be deterministic given the same input, and our
minifier is no different. But, what kind of change do we expect when
the input does change? Well, in our case, we minify the code into
lines of upto around 1000 characters. This means every once in a while
a line break is let through.
In my unrelated patch, the amount of code above this test case
changed, so it changed where each compression chunk starts and ends,
and thus ended up no longer placing a line break in one of this test
case's functions.
== The fix ==
Define this function with a string literal and eval, so that it is
unaffected by minification.
== Long term ==
These kinds of subtle differences in optimisation are common to most
minifiers, and are thus unavoidable in practice. The better solution
I think is to run our tests in debug mode. I already intend to do
this after T250045, and this patch is another reason to do that,
albeit the first time in 11 years that we've run into this!
Change-Id: Ibab369ae193a7b99616da1ccef93ab4850b8686a
Previously, getMessages() only worked with fewer than 50 messages
(depending on user rights), and reject with API error "toomanyvalues"
if asking for more.
Bug: T290208
Change-Id: Icc5711a0017eff25788b4fb71b8ab7ec25ef0efe
This measurement was unaware of the new packageFiles feature of
FileModule.
* Remove attempt to normalise String(function) across browsers.
I don't think the extra handful of individual bytes matter,
especially since the console UI for this usually rounds large
numbers to the nearest 0.1 kB anyway.
* Remove generalised argument trimming.
This was copying all of PHP trimArray(), but didn't need to because
if an empty object were to be passed as 'messages' or 'templates',
then that means it was actually sent, stored, and thus should be
measured. In mw.loader.implement, the default is null, not empty
object. I believe this may have been different at some point,
but at least not today.
* Remove generalized serializing. All values can be passed to
JSON.stringify except 'script'. Handle only 'script' in its own
way, the rest can be an inline assignment.
* Improve the new serializeModuleScript function to support
packageFiles, by serializing them the same way as mw.loader.store
does. I considered abstracting and re-using this but I found it
not worth adding cost and abstraction for. This is low-level, stable
and perf-sensitive code that has sit idly for many years, and will
likely sit idly after this one change for years to come. An inline
comment should suffice to change both if and when the time comes.
Either way, it's a debug feature, and not critical code. And it
also extensively covered by tests.
Bug: T289889
Change-Id: Ib1e4acd438990677f365a3668f786f16f2671862
The method is documented as being used in
ResourceLoaderJqueryMsgModule, but that was removed. The only
existing callers are in qunit tests - the base test runner calls
mw.jqueryMsg.setParserDefaults to update the reference to the
messages to use, and the jqueryMsg tests call the method in
order to test it. Since the base test runner doesn't use the `deep`
option, its only being invoked in the tests for the functionality -
remove the functionality and the tests for it.
Follow-up: I203d4e3ecdeeeb16729eba2dcf40d11a41d2e582
Change-Id: I28a28175dd295f631d63034e98481c357e0189ab
In PHP, Title::getLinkURL() and related methods will make a
fragment-only link in this case (and ignore the given query
parameters). In JS we previously generated a link to the main page.
Change the JS code to match. Also add a unit test for this in PHP.
This also affects mw.Title#getUrl and the parsing of messages using
mediawiki.jqueryMsg.
Bug: T288415
Change-Id: I4aeba3409581f6a1d49a17e823ec83d8b76b844f
This change renames the existing method `codePointAt` to `charAt` and
make it public. This method is similar to `String.prototype.charAt()`
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/charAt
but supports Unicode characters outside of the BMP.
The name `codePointAt` would be irritating because the method
`String.prototype.codePointAt()`
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/codePointAt
returns the code point number of the character instead of the character
as string.
Use this method to fix in the module 'mediawiki.jqueryMsg' the
functions `int`, `ucfirst` and `lcfirst` for strings with a character
outside of the Unicode BMP as first character.
Also add tests and use the usual Unicode syntax in the tests.
Bug: T285174
Change-Id: I4343e628e846de44cfdf0405261fa1a8d7ffbed3
This works correctly when the fragment identifier is percent-encoded,
and relies on the browser to handle the annoying work of decoding it.
Follow-up to 599c80d06e.
Bug: T283959
Change-Id: I6062912b496a85d5838580824dbfcbfc726f896c
Added some tests to the mediawiki.base.test.js suite, testing behavior
of mw.hooks on:
* Unmatching number of arguments between the handler and the fired
event.
* Memory with information of the alst fired event is not cleared when
"consumed".
* Testing chained add.remove.fire sequence works synchronously, the
handler is removed before the event is fired.
Bug: T223352
Change-Id: I64ec326374c9ac69491bd95e55203f247bd12e3c
We can't avoid this entirely where we're testing upstream features
that are yet to be renamed, but this is a start.
Bug:T277986
Change-Id: I5c1ae717cc008ca147ea31fe35c44b19d1fe5d98
Exceptions from one mw.hook handler should not affect another.
This expectation stems from how other systems work, such as
jQuery.ready, Promise, and DOM event listeners.
mw.hook used to be a shortcut to $.Callbacks(), which is the same API
that powers jQuery.ready and $.Deferred, but it is lower level and
before such error handling is used. With commit 9f23dfa47b I have
replaced with with a simple handling of our own with just the part
we need, and this commit improved that implementation with error
handling.
Bug: T223352
Change-Id: I380b93ab3de1b3b7e5f0c5effa2e367fa9b1e6f3
Known issue: If you scroll to a fragment via hash, collapse a parent,
and then click a link to the same fragment or press Enter in the address
bar, the scrolling won't happen. This is because the hashchange event
doesn't get fired, and I doubt there's a good solution.
Bug: T276741
Change-Id: Ibd42d4a051b7bb07beeea4a36b0dc5977f315518
A table can be created with an incorrect rowspan value if a row
is later deleted. This doesn't impact sorting, so shouldn't throw
a JavaScript error.
Added test case.
Bug: T265503
Change-Id: I15bbd12fb29560d3986b6f2a60d09ab7c8a980f7
Create mw.errorLogger.logError() so that developers can both handle and
log errors thrown by their components.
A motivating usecase is logging thrown by Vue.js components. By default,
those errors are caught by the Vue.js runtime and logged via
console.error(). However, this behavior can be overriden.
Supporting changes:
- The mw.errorLogger API is defined in the mediawiki.base RL module and
so is loaded during the critical path. In order to minimize the size
of the payload, all code related to the parsing/normalization of stack
traces has been moved to the WikimediaEvents extension
Bug: T249826
Change-Id: I413c4bf58b79dd86e2023a230d9cad7198e975e6
* Add tests for was untested fallback logic.
* Rename 'hidden' to 'HIDDEN' to make it clearer that this is not a
(dynamic) boolean but a string constant.
* Remove case for msHidden. The best I can tell, this was never a thing
in any version of IE. Similar code in EventLogging, for example, does
not contain this case either. CanIUse and MDN confirm that this is
supported through the standard since IE10+, including IE11.
<https://caniuse.com/mdn-api_document_hidden>
* Document that the 'else' branch for `document[ HIDDEN ]` is
handling both the 'visible' case and the "unsupported API" case.
* Define local functions normally as such. Avoid confusing var assignments
for functions that are not dynamic or conditional.
* Clean up 'init':
- Use under the same name in source and in test.
- Avoid shadowing variable 'document'.
- Move default logic to `init()` so that it must be called before
use, instead of previously where it could work without it.
This also makes it easier to restore, and allows the real global
to be explicitly references as such for improved static analysis.
- Add missing restoration to test suite.
* Remove redundant closure from test suite file.
Change-Id: I6180682f49781e51551048c2d16ca40c044dda98
Create mw.errorLogger.logError() so that developers can log errors that,
for whatever reason, won't cause the JavaScript runtime to raise an
error event on the window object.
A motivating usecase is logging thrown by Vue.js components. Those
errors are caught by the Vue.js runtime and logged via console.error().
Bug: T249826
Change-Id: Icdb5ea4678df61d8cb7fd5cba5091cab1ec5b7cb
mw.util.getParamValue should return null, not throw exceptions,
on input it cannot decode.
Bug: T268058
Change-Id: I8b565f781b1631a545fdf1b220fbb16976b99ea6
The collapsibility/visibility of the table of contents is a skin decision. A skin for
example may choose to not make the table of contents collapsible - in
fact this is planned for Vector in a future version:
https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features#Table_of_contents
The test no longer makes sense in core so the check for visibility
is removed here. Vector will be a better location for the test if we want
to retain this for the legacy skins.
Bug: T252774
Change-Id: I876ce99363d6c594516c983bbfac9db7cbe770be
Language::commafy was deprecated; it is poorly named, and its functionality
is rolled into ::formatNum/::formatNumNoSeparators.
Deprecate mediawiki.language.commafy for similar reasons, and because
it parallels a deprecated core PHP method. Perhaps it would be
worthwhile to add a new JS method in the future more closely matching
the PHP ::formatNum/::formatNumNoSeparators pair.
Code search: https://codesearch.wmcloud.org/search/?q=commafy%5C%28&i=nope&files=&repos=
Change-Id: Id3fc5dc2c7e62495a532db93d85a6f1cb8e8cbeb
* Update digitGroupingPattern to match CLDR 31: New versions of CLDR has
digit grouping pattern with decimal part. Update digitGroupingPattern
values in Message classes with this improved pattern.
Refer: http://unicode.org/reports/tr35/tr35-numbers.html
* Refer the following chart for the decimal patterns.
http://www.unicode.org/cldr/charts/31/by_type/numbers.number_formatting_patterns.html
* Uses PHP NumberFormatter class for the commafy implementation, which
is available in PHP 7.
* Some tests need to update to match the TR 35 spec
* The formatNum public method in Language.php is the preferred way to
use this feature. It does separator transformation and digit transformation
wherever applicable.
* Renamed the second param name for formatNum from noCommafy to noSeparators
* commafy method is deprecated and formatNum is preferred. Practically,
we are not just adding comma, but seperators according to the language.
Replaced some tests based on commafy methods with tests based on formatNum.
Note: The corresponding js implementation is not changed in this commit.
It would probably be a good idea to use globalize.js, which is also based
on the CLDR patterns.
Note: This patch preserves the existing off-by-one error in
$minimumGroupingDigits; T262500 will eventually fix this.
Bug: T167088
Co-Authored-By: C. Scott Ananian <cscott@cscott.net>
Change-Id: Ic721b9a91e78e4ef07040339d1006b7a90a910c0
Provide the equivalent functionality of WebRequest::getCrossSiteCookie()
and the sameSite and sameSiteLegacy options in WebResponse::setCookie()
in mediawiki.cookie.
Bug: T257936
Change-Id: I88a970bb00c672a9c23569ec791be51d07cae59d
This basically makes it equivalent to .escaped() and not .text().
Does not affect the mediawiki.jqueryMsg version, which still accepts
whitelisted HTML tags.
CVE-2020-25828
Bug: T115888
Change-Id: I6513dfb480024309e1594abc6f07bbd3b0c5a10e
