In Minerva addPortletLink creates a <ul> tag underneath another
<ul> tag (not inside a <li> tag) which is invalid HTML.
This function should consider that the id of the portlet may be
the list to be added to itself
Bug: T231925
Change-Id: I25c4d2d93a38368ee784f5bce7900885a3ff520a
When something loaded the module 'mediawiki.diff.styles' on
Special:JavaScriptTest (this happens e.g. with VisualEditor),
the diffs generated for failing tests were grotesquely stretched
and useless. Add some style overrides to restore sanity.
Change-Id: I8ac6a2c6e86c6e982fad5d628d3b2c96efc4fbc2
This was still providing support for various browsers where JS
is unconditionally disabled in the Startup module, hence the code
is never used.
Keep the information about them as historical note for now since
this file has become a historical record of sorts about
accessKeyLabel, which may be useful at some point.
* Remove old Opera code.
* Remove old Firefox code.
* Remove old Konqueror code.
* Remove old Safari code.
* Remove Safari on Windows code (macOS-only as of Safari 6).
Also:
* Rename internal name for getAccessKeyModifiers() parameter
from 'ua' to 'nav' because it takes a Navigator object,
not a userAgent string (per $.client.profile).
* Add test case for newer Konqueror.
Copied from <https://github.com/wikimedia/jquery-client/commit/ae3e7fb294>.
Bug: T233676
Change-Id: I0cdbc3207f33e5b34f1d814c0b9b50f664b5b67c
The signature with two parameters, the second one being an options
object, is unused:
https://codesearch.wmflabs.org/search/?q=Title.newFromUserInput&i=1
Not only that. It was broken before. This patch is not changing the
current behavior of this function! An options object passed as the
second argument was ignored before.
The method exists since I260ba88 from 2014. The alternative signature
broke with I61c7e73 from December 2018.
Arguments for not announcing this as a breaking change:
* We know it's unused (at least in code we monitor).
* It's broken for half a year, and nobody noticed.
* There is only one option anyway, "forUploading". It defaults to true,
which is the more strict mode, and what code usually wants.
Change-Id: I6cf951d1e6f015bcd3749859c9baf002f7c82cf4
After commit bbded40a2b, the stub for mw.track no longer worked
as originally intended, causing the stack traces to be printed
to the Karma output and browser console again.
The test still passed because mw.trackError calls mw.track, but
it no longer stubbed out the trace logging noise.
Also simplify some assertion messages while at it, these are meant
to describe the subject (the compared value) not be the value
itself (which is the second param) and not the error message
(which QUnit produces).
Change-Id: I657bf4479a40e1b73b45426df98882aed32b4cba
These are silently skipped and generally no cause for alarm.
For example, when enabling a gadget by default and then
disabling/deleting it, cached HTML will still have it queued,
which is silently skipped and the other queued modules are loaded
just fine.
The same for when merging module bundles where the destination
is already loaded, in such case it is tolerated to let cached
ParserOutput objects still queuing it silently skip it.
Keeping it existent just to avoid a warning isn't particularly
useful and might even obscure problems or give the illusion that
it is still working and providing compatibility (e.g. loading the
new code), which might not be true.
The silent skipping of modules originally did not have any
logging or warning attached to it, it was silent from 2010
to April 2019. In 2017, commit 37df741514 adds a console warning
when a circular dependency is detected.
In April 2019, commit d059dffa2 optimised away this redundant
silent skipping of unknown modules, in favour of re-using the
code for circular dep detection, which did the same thing already,
but with a debug warning. This meant it now showed scary stack
traces when all there's only an stale module ref, which are normal
in RL and generaly nothing to worry about. This was amplified
by Minerva's tracking of client-side errors going beyond just
'global.error' but also listerning to recoverable internal errors
from 'resourceloader.exception', which now included these
debug warnings.
Change-Id: Ie71adbe18e8dbeb661ddb9d7d3d1d0897891d515
If the foreign API has the same host as the current page (e. g. if it’s
actually the same wiki, or multiple wikis are installed under different
paths on the same host), then the browser will not send an Origin
header, and if we still set an origin parameter, then the API will
complain that the two don’t match. Detect this and unset the origin
parameter in that case.
Bug: T208601
Change-Id: Ia006f3dc3283ce3f81d4d72cbe9676a00797c4d0
I split this out of it back in 2011 with 83a7822df7.
I don't remember why. I think it had something to do with
Special:JavaScriptTest where I wanted to do something with colors.
Having those functions is useful in theory, but that doesn't require
its own module.
Change-Id: I8815d32c7072da83ddb9fbf955534d1f954692ba
In a nut shell:
* We very often (52% of modules on enwiki) pad the hash with a zero,
which means the amount of bits we currently compute already fit in
6 characters already for most modules. For some modules (3%) we
even padded two zeroes.
* For the (now documented) use cases, the space of 78 Giga
(78 billion, or 78 milliard) seems more than we need. The space of
60 million should be enough.
This follows-up dfd046412f from 2016, which previously shortened the hash
down from 8 chars of base 64 (or 12 chars of hex) to 7 chars of base 32.
Before that change, the space was 281 Tera (64^8, or 16^12).
For more details see the added inline comment for ResourceLoader::makeHash,
and also the data at <https://phabricator.wikimedia.org/T229245>.
Bug: T229245
Change-Id: I9ad11772a33b3a44cb625275b1d7353e1393ee49
Added originally in c46fc745a9 based on the support document for
jQuery Mobile 1.3, via <https://jquerymobile.com/browser-support/1.3/>.
These have been obsolete since T102318 because startup.js is now a feature
test, with UA-snifs only for browsers that both *do* have all Grade A
capabilities for which we still want to disable the JS pipeline.
* Palm WebOS: Upstream jQuery 1.x allegedly worked fine on WebOS 1.4+.
Not sure why we excluded WebOS <= 1.4, looks like that should have
been <= 1.3 instead.
If it doesn't have the neccecary HTML5/ES5/CSS3 features,
it will remain in Grade C without a sniff. Otherwise, it's probably
fine to enable. Either way, not officially supported (Grade X).
Usage on WMF wikis is presumed less than 0.1% as neiter Palm nor
WebOS show up on https://analytics.wikimedia.org/.
The example UAs mention WebKit/525 and WebKit/532 which
correlate with Safari 3.x and Safari 4.x, which we know
doesn't pass the feature test.
* Symbian:
The example UAs mention WebKit/413 which corelates with Safari 2,
which we know doesn't pass the feature test.
Change-Id: I62a83e3b4967f309739095d9c73650f9859ee856
When the new 'arrayParams' option is set, query strings like
`&foo[0]=a&foo[1]=b` will be parsed as a single parameter `foo`
containing an array, rather than two separate parameters.
The new option also affects the behavior of array parameters like
`&foo[]=a&foo[]=b`, which will be parsed as a parameter named `foo`
rather than `foo[]`, and disables array handling for parameters that
don't contain an array index at the end.
Unlike in PHP, this does not handle associative or multi-dimensional
arrays, but that may be improved in the future.
Bug: T231382
Change-Id: I48d4bb3fdf0ea7f5eb133c59bf63651ba356fc42
Our version hashes are 6-7 chars of base36 from a fnv132 digest.
Using the formula of <https://en.wikipedia.org/wiki/Birthday_attack>
that provides enough range to publish 2087 different versions of
a given module before there is a 0.1% probability to clash with
another version, 660 versions for a 0.01% probability, and
209 versions of a 0.001% probability.
I think 200 versions of a single module is a good enough space
for most use cases we have of the version hash (such as the E-Tag
header for browser caches and HTTP proxies, whic have have a 30-day
TTL).
However, for mw.loader.store it's a bit tricky. It's generally
more than enough given that (unlike HTTP caches) we only store
1 version of any given module so we don't need it to be different
from N different versions, just the last one.
But, also unlike HTTP caches, localStorage has no expiry. This means
that while for a single user it only has to be different from their
last-seen version, but from the server perspective, it needs to be
different from all possible versions a given user may have last seen.
This is problematic and effectively unbounded.
Plug this hole by discarding the localStorage value and starting
fresh, if the user last visited the site more than 30 days ago.
This is also in preparation for T229245, which will reduce the
hash from 6-7 chars to 5 chars. With that size, we can support only
348 different versions at a 0.1% probability (instead of 2087).
Which is fine for the bounded use cases with a TTL, but would make
the unbounded nature of localStorage even more problematic.
Bug: T229245
Change-Id: Iba8cdbebf1bb5c7c628832708fd656fcef61c095
This is in preparation for changing the way group indexes are transmitted
between the server and client, to confirm that the behaviour doesn't break.
Change-Id: I1f84c4c407a4eb69b5b9659d768c643d4a83df0d
Follows-up 1c7c9bdf1f.
* Define the method only in test context, instead of
a run-time check.
* Return the old value, and re-use function for restoring
the result afterwards.
* Make the test define its options by default, so at to not
rely on local-wiki defaults in any way.
Change-Id: I71e92d5b9ee789b594e6e64ca3e425583fc1ee1c
Use
mw.util.wikiScript( 'load' )
instead of
mw.config.get( 'wgLoadScript' )
The module 'mediawiki.util' now gets the value from a private config
variable.
Change-Id: Iae4f4754f40999ba9d7c7161e9a37820c4b5931c
Previously removed from includes/ already.
Also remove odd `@package`, which we never use.
And remove `@since` which doesn't make sense for test-only files.
Change-Id: Ib7265d39329ecadd5279b11820f77f54189b55d2
This should reduce the need for the collationRegex.
It also removes the need for the lowercase based sorting, and
lowercase vs. uppercase order is now determined by the selected
locale.
Android Webviews don't support this, so fallback to the old sort
routine is required.
Have not removed collation regex yet, as the
level of support for specific locales is not entirely clear to me.
Maybe something we should gather statistics for.
Bug: T32674
Bug: T47070
Change-Id: Ie7fe7317471eb12d6a65dfe3c68858c7dc0e92dc
In commit bb084a3573 I assumed that
with uselang=qqx, any messages defined in JavaScript would be just
the message key wrapped in parentheses.
It turns out that extensions (e.g. VisualEditor) have been sneaking
in messages in content language using the system we assumed to only
contain messages in user language. This trick stopped working.
Detect this and return the real message, if it's defined.
Bug: T222944
Change-Id: I3f2a6ceb249402ef76e788c494fd5bdc519faf65
This patch also does:
* Fix the behavior for filenames that have a dot, but no file
extension after the dot.
* Add missing test cases.
It seems like this method is barely used anywhere:
https://codesearch.wmflabs.org/search/?q=newFromUserInput&i=1
So we might as well remove it, and inline simplified versions that
only do exactly the normalizations that are needed. For example,
silently stripping leading colons is a somewhat suprising thing to
do. Shouldn't such a title be invalid, instead of silently being
converted to something else? But this is unrelated to what this
patch does.
Change-Id: I1596fb0d9d02ca230a37f3d70d65296d6ce4ddb4
