SearchInputWidget is similar to a TitleInputWidget, but doesn't has
a visible loading indication, doesn't highlight the first result and
uses the opensearch api endpoint for suggestions, instead of
prefixsearch.
Extra points:
* Improve documentation of mw.widgets.TitleInputWidget's configuration
option validateTitle
Bug: T118443
Change-Id: I8b8098041fe2971389fa908d007d2e77255829ec
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
I wasn't reading through them very carefully, so it's possible
that some of the 'oojs-ui-widgets' could be narrowed down further
to just 'oojs-ui-core', but this is good enough for me. At least
we're no longer loading toolbars everywhere.
Change-Id: I58799e22f9c0a2f78c1b4a02c4b7af576157883a
The BookletLayout now emits events during the upload file phase. It
uses these events to update a progress bar at the top of infoForm.
Bug: T115861
Change-Id: I0fd7f21f3fc1ef042330b7571c247e09c24d1a5c
We don't want it to accidentally end up in MediaWiki 1.27 release.
It can be restored again when needed.
This reverts commit d0e47d475c.
Bug: T120867
Change-Id: Ie1a90ad2d2ccdecf189313e18c3c5b24576363f4
Broken with the switch to OOUI.
This also adds 'id' param to OOUI HTMLRadioField.
Follow-up to b51076a844.
Change-Id: I69c5fa9830a8b8b7cd6bf3468b5600325d34c070
This implements a new JavaScript module, mediawiki.checkboxtoggle.
The module is suitable to be reused in any other list of checkboxes.
Bug: T92230
Change-Id: I92141a7079fc7fcd7152ef418d82f4f7969b163b
Loading CSS with OutputPage::addModules() causes a FOUC because the
styles are loaded through JavaScript, using addModuleStyles() fixes
this. But it doesn't load module dependencies, so load the
mediawiki.hlist styles explicitly in ApiHelp.
Bug: T117901
Change-Id: I1dfd194d686c05573eefc85d5dfd7ee2731bf286
jquery.validate was added in r99929, presumably for Gadgets 3.0 work.
However it's entirely unused in core, extensions in Gerrit, and on
Wikimedia sites. Even if Gadgets 3.0 were to require it, it should
probably live in the Gadgets extension rather than core.
Change-Id: Iebe09e853a6eb67af4a06b296606a8193df18d34
Since OOJS-UI isn't currently in a position to accept such things, the
decision is to put it in MediaWiki instead. Once OOJS-UI is
un-monolithicized and the i18n issue is solved, this should be somehow
moved there instead.
Change-Id: Ia3942c76804c865c1039904d170ee6eafcdc6793
Switch to OOUI HtmlForm and replace mediawiki.userSuggest with
OOUI HtmlForm type user.
Bug: T117734
Change-Id: I37d9acbdd272c0cc2f2e120aada2e9fcea215509
Copied the following string from UploadWizard into core to be shown as
help text near the input fields:
* mwe-upwiz-tooltip-title
* mwe-upwiz-tooltip-description
Bug: T116086
Change-Id: Iaaac4908c71b416888921a4e45de66fa87ab448d
Also:
* Strip/replace characters that are invalid in MediaWiki page titles
from the default file name using mw.Title.newFromFileName
* Upload files with the canonical extension for given file type (e.g.
map '.JPEG' to '.jpg') using mw.Title.normalizeExtension
Change-Id: Ied06682a61581303b720096bb087fc2d9ae4fdbe
Use the file's lastModified date, or EXIF DateTimeOriginal (where
available) as the default value of the DateInputWidget instead of
leaving it blank.
A lot of the code here is from mw.UploadWizardUpload.prototype.checkFile.
Bug: T115863
Change-Id: I75adec9718d89a7177050e8b848478d1b0069dd0
Added mobile target to its entry in Resources.php. Tested in
Chromium dev tools with various emulated mobile devices and it Just
Works.
Bug: T93262
Change-Id: Idb416b0877ea5a3764936389dfe59d4653ad96d0
We're almost ready to drop the non-plain mode of Special:JavaScriptTest
in favour of Special:JavaScript/qunit/plain. There's a few mobile-related
extensions still using the non-karma mode for qunit testing.
However, none of them make use of the Skin selector, which was mainly a debug
thing I added in the initial version. It no longer makes sense since our tests
now enforce an anti-dependency on skin html and other context. Encouraging
testing in multiple skins in the old UI therefore no longer makes sense.
This also fixes one of the most frequent errors in resourceloader logs and gets
rid of an ugly hack in Resources.php that causes a small amount of overhead
in ResourceLoader::__construct().
> MessageBlobStore failed to find skinname-fallback
> MessageBlobStore failed to find skinname-apioutput
Change-Id: Idaacf718703883c6a7e83a17ccd3f41ebdca53d1
Second attempt. First, reverted one: I6f68122b5399f4b8766825c752e964478ae7563d.
To improve in the future:
* Use a better error message when not all logged-in users can upload
Bug: T115866
Change-Id: I1ac083fd491c7445240b4fd9f7b3badacb2d2d37
Add higher quality PNGs. Also added SVGs, and now using the
.background-image-svg() mixing to use SVGs.
Change-Id: I8d8fbf8e58b4ef5d9956731c8b85d5db07b3f5ed
It turns out that people click the checkbox affirming that they are
they author of the file and that they release it under CC BY-SA even
when neither of those is true. So we're trying some interfaces that
require a modicum of thought rather than just a click on "I agree".
Option 1: The form we have right now, with a single checkbox.
Option 2: Four checkboxes, each with a label explaining one facet of
the requirements (own work; no pictures of copyrighted work;
educational/useful; irrevocably released as CC BY-SA).
Option 3: Some Yes/No questions structured so that 'Yes' is not
always the right answer to continue uploading.
Option 4: Longer introduction before a single checkbox (as in option
1), with examples of good and unacceptable content.
As only logged in users are able to upload files, we're able to bucket
them into four groups by user ID number. When the user completes a
file upload, the bucket number is saved server-side in a change tag by
the companion patch I90cb12c505b2581f36113ec6b4f7bf732f0971b7 (we could
match the user IDs cross-wiki by username, but that sounds painful).
For testing and debugging, add '?uploadbucket=N' to the URL to force
given interface option to appear. Any completed upload won't count
towards the bucket.
Note that for expediency, the tested options all assume uploads to
'shared' repository (that is, Wikimedia Commons). The winner's
messages will be tweaked to work with 'local' and other targets too.
This patch DOES NOT ENABLE THE TEST yet, it just implements the options.
Enabling it on specific wikis can be done via config:
* $wgForeignUploadTestEnabled = true/false (defaults to 'false')
Whether the test is running.
* $wgForeignUploadTestDefault = 1/2/3/4 (defaults to '1')
Interface to use when the test is not running (and for anons).
Bug: T120867
Bug: T121021
Change-Id: I557056b867c6a55ef2c9af321eb48893312632a3
It stopped working after 6b9a1c6d5b
accidentally changed the 'id' of the text input this was validating.
It seems that all browsers these days have some validation for 'email'
fields, so this isn't very useful, and the styling of the notice looks
pretty jarring with the current 'ooui'-style form.
Change-Id: Ifa3103c9c9369654ea1cd4b064a67454b8694bf0
Allow passing in an external api.php URL to post a message on a remote
wiki. Note that the remote content model must have its messagePoster
implementation registered on the local wiki for this to work.
Bug: T111590
Change-Id: Id52b7d3a12ed5e57e29d3f22fb7f4f36b8a908b1
This change moves the rules for the CSS classes that only
get used by JavaScript into the same module 'mediawiki.toc'.
This module already gets loaded via JavaScript.
This way, the styles are only loaded when they are needed.
Cached HTML pages already contain the module 'mediawiki.toc'
so there is no problem on deployment.
Change-Id: Ib7c81e9433e7e3976e40e407f63fc8e924957faa
The biggest negative point (as far as I can tell) with the change mentioned in the follow-up
is, that a user needs at least 3 clicks to change an option, which before it required only
one click. This option adds a new preference for the watchlist (which can be enabled/disabled
using Special:Preferences) which, if enabled, loads a new, tiny module with a script, that
listens on all input and select fields in the header form of Special:Watchlist. Whenever one
of these elements get changed, the watchlist form will be submitted automatically.
The default for this option is false (disabled).
Follow up: I3bcd27596c21aa4
Bug: T50615
Bug: T119322
Change-Id: Icab1a5143df24a06f468165421d40db8fa57e73c
* Add a 'title' attribute like for wikitext links
* Add a 'missing' property to make it easy to check for redlinks
in the input programatically
Change-Id: I647af4dee947a6572f0202cf6b8b28777bbdc17e
This message does not exist in MediaWiki core. And even if one creates it locally,
it is not used by MediaWiki.
It is used for the p-logo link (not the section). And for individual links in
the toolbox and other portlet sections. But not for the sections themselves,
those only have labels (typically rendered as <h3> or something).
This reference was spamming logs with:
> [resourceloader] MessageBlobStore::fetchMessage failed to find tooltip-p-lang (en)
Change-Id: Ie1420230dc0857c1e38641697098b4adb2b28afb
