Mostly remove it at least. Some things from the transition are still
left around:
* EditPage::isOouiEnabled() will now always return true and is soft
deprecated as some extensions are using it to detect whether in OOUI
mode.
* EditPage::getCheckboxes() is left around since getCheckboxesOOUI()
calls it. Someone else will need to disentangle that.
* The "mw-editform-ooui" class is kept as some on-wiki JavaScript uses
it to detect whether running in the OOUI mode.
* CSS is still using the .mw-editform-ooui class. It should be
transitioned to use .mw-editform in a follow-up.
Other cleanup:
* mediawiki.action.edit now directly depends upon oojs-ui-core instead
of transitively via mediawiki.widgets.visibleByteLimit. As a result, the
mw.loader.using call was removed from the JavaScript file.
Bug: T172315
Change-Id: I2b468c8b846db015b5a1e3d2500abb8ea252c442
For accessibility, add title attribute to the remove button in
the active filters area.
Bug: T173608
Change-Id: Idcf735e3b610345a8206f83fe5f8115900455cc2
For accessibility and screen readers, add the actual highlighted
filter names to a title attribute in rows that are highlighted.
Bug: T173608
Change-Id: Id71a45621e545897988010acfd054760a617b1f1
* 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
When the 'watchlistunwatchlinks' preference option is enabled, this
adds a '×' link to each entry of the watchlist that unwatches the page
of that entry. When clicked, it changes into a '+' which can be used to
re-watch the page (effectively undoing the earlier unwatch).
When a page is unwatched, its entries and the entries of its associated
talk page (or vice versa) become translucent and are struck through.
Without JS, '×'/'+' link to action=(un)watch for the relevant page.
In addition, ChangesList classes have been modified to allow a prefixer
that adds a prefix to each line (used in this case to put the unwatch
link) and to add HTML data attributes to reliably determine the target
page of each entry. Unit tests have been updated accordingly.
Bug: T2424
Change-Id: I450b2901413d7e75c11de2a446829fdbb22d31e1
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
When "live update" is off and new changes are detected,
show a link to load and prepend the changes to the list.
Also adding a line between old and new changes
when grouping by pages is off.
Bug: T163426
Change-Id: I6a111d23956bdc04caa4c71e9deede056779aafa
When creating a new saved query, there's a checkbox
to set it as default as the same time.
Bug: T171922
Change-Id: Id6da0e79c54bc65d76636bbff64b2ece568c0cd4
Minerva explicitly disables it
These are needed for rendering for:
?useformat=mobile&useskin=vector
Change-Id: I759c023b4ce63186929b893953042fc0a5059aa2
This allows skins to define how hlists appear (e.g. which pseudo
elements to use or whether to use them at all) while
providing some sensible defaults.
Bug: T42062
Change-Id: I61b5f077d8b4a4c7fe845b7b6d1df98bb2dbafc8
Typing a search query into the main box on Special:Search
causes the search to be performed for the first autocomplete
result, rather than the typed query. The first autocomplet
result should only be searched for if explicitly selected with
the mouse or arrow key.
This reverts commit 7882e3b660.
Bug: T171112
Change-Id: I1af6ba90542fafe3ed1aeca420e9d6df6612f7d0
- Add 'hidden' groups that have base defaults but are not
viewed in the filter drop-down.
- Add a UI for days, hours and limit selections, based on their
group models.
- Clean up the fieldset form to remove redundant line breaks
and empty objects.
- Add 'hours' as a subset of days, where the UI can split itself
by picking up values >=1 and <1
- Add the ability to allow 'arbitrary' information from the URL
values, but also make sure there is a validation method
and a possibility to re-sort the values that are added in.
Bug: T162784
Bug: T162786
Change-Id: I8068a7cc411eef40ddb8af4eef1d4f1e5f2a2b82
Adds a live updates button that refreshes the changes list every 3 seconds.
For now this is pretty dumb in that it re-requests the entire list every time;
the next step would be to make it only load new changes using the &from=
query parameter.
Bug: T167743
Change-Id: Ic2ddea840e5c46f42b32ae4fff91138cacc28ec0
MobileFrontend silently removes this skin from the page. This is
now made explicit and the module can be safely loaded in a mobile
environment.
This is used by both Timeless which although does not work
perfectly on a mobile device it should be easy to fix with additional
work.
Change-Id: Iedea2872d14430db452cec7e758f20d854778414
Depends-On: Ic36e9792f9217f3fd37bbd1f5c66d894301363f0
Mixin mw.widgets.TitleWidget instead of extending mw.widgets.TitleInputWidget.
* Remove code that reimplemented pieces of OO.ui.SearchInputWidget.
* Remove code that overrode pieces of mw.widgets.TitleInputWidget.
* Copy the code from mw.widgets.TitleInputWidget that we actually want.
This should result in no functional changes, other than losing the
TitleInputWidget API (some methods and config options) that no one
relied on, as far as I can tell.
Bug: T169194
Change-Id: Ic1482b4c7cfde7d4cf0b8900654bd3a454776010
- Correct language in the 'apply' button
- Add a placeholder to the input
- Make the 'apply' button disabled if the input is empty
- Remove the use of the OOUI-built-in validation, since all
we do is "validate" that the input isn't empty, and there's
no need to show error mode (red border) for that, especially
since the 'apply' button is disabled in that case.
Bug: T169042
Change-Id: I5e3600b1ac8e63d8a25c0540468fe42febfc3a70
- Allow for multiple footers for the menu, each configured
for its own view (or multiple views)
- Move the switch view buttons to the right of the input
- Add a 'back' button on the menu header when we're in
advanced filters view, moving back to default view
Bug: T167384
Change-Id: I9fd0243f88f92ddacb4c912ff974f7d325f32f5d
Hopefully uncontroversial.
Mobile non-js editing is currently feature flagged
by $wgMFAllowNonJavaScriptEditing so this shouldn't have
any impact on production but will ensure the editor gets
styled consistently with future changes here.
Change-Id: If8994370e9ec7fc424ce7cb22df922d029cfc035
The module's summary will be used as the description of the value.
Since these are often very long lists, this also changes ApiSandbox to
collapse <dl> lists in parameter descriptions by default.
Bug: T123930
Change-Id: I205b68a52a94cae4c1cdf7ec9fd3e8a04d565919
ApiMain will add a header to indicate that lacksSameOriginSecurity()
forced the request to be processed as if logged out, and ApiSandbox will
detect this header to display a helpful message on the results page.
Bug: T165797
Change-Id: I56390b31563c75d83cf0a8ffb1b8e4f3283895f0
.updateTooltipAccessKeys() is called automatically after the page
loads (from mediawiki.page.ready), but infusing the field blows away
these changes.
This is a poor workaround, the same issue will appear if e.g. the
buttons are infused. The functionality provided by jquery.accessKeyLabel
should be an OOjs UI feature, or we should somehow call it automatically
after infusing widgets.
Bug: T168042
Change-Id: I2b166be34b8394c296fbc7326570cd732284888f
Fetches the tags from the wiki and displays them as additional
filters for RCFilters.
Bug: T159942
Bug: T161650
Bug: T164130
Change-Id: I7bfa99cd5aeb34b6c7de74c15aac158ee40eac2f
Enhanced RCFilters: Add the ability to filter by namespaces to RCFilters.
🎉🎁🎊
- Add the ability to separate groups of filters by 'views'
- Add the first views as 'default' (for predefined filters)
and 'namespace' as the list of namespaces.
- Add 'nsinvert' to namespace group
- Allow highlighting namespaces
- Allow searching on either view, depending on prefix
- Add a way to switch views by typing prefix, clicking the
'Namespaces' button or clicking a tag (either namespace
or filter tag, changes the view accordingly, and adds
or removes the prefix from the input to stay consistent)
- Add an optional wrapper text for tags, so we can represent
them with their respective prefixes and (if needed) with
a special message for inverted state.
- Add unit tests and make pass
- Bonus: Fix issue with URL not updating (and not being updated)
the inverted and highlight enabled states.
Bug: T159942
Bug: T163521
Bug: T164130
Change-Id: I7e83f0800cbeb289dfd3461c1c5a197c053147ca
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
resources/src/mediawiki/mediawiki.filewarning.js
* Add 'alerts' as it uses 'alert'
resources/src/mediawiki/page/gallery-slideshow.js:
* Add 'movement' as it uses 'previous' and 'next'
resources/src/mediawiki.special/mediawiki.special.apisandbox.js:
* Add 'content' as it uses 'info'
* Add 'interactions' as it uses 'add' and 'help'
* Add 'editing-advanced' as it uses 'code'
resources/src/mediawiki.widgets/mw.widgets.CalendarWidget.js:
* Add 'movement' as it uses 'collapse', 'previous', and 'next'
includes/widget/SearchInputWidget.php and
resources/src/mediawiki.widgets/mw.widgets.SearchInputWidget.js:
* Add 'interactions' as it uses 'search'
resources/src/mediawiki.widgets.datetime/CalendarWidget.js:
* Add 'movement' as it uses 'previous' and 'next'
Bug: T166730
Change-Id: I0618c681d06891621470ca1cb500dedfdf05f93b
includes/resourceloader/ResourceLoaderOOUIModule.php
* New trait centralizing some logic for dealing with OOjs UI themes,
previously duplicated in OutputPage, ResourcesOOUI.php and
ResourceLoaderOOUIImageModule.
* Follow-up change I74362f0fc215b26f1f104ce7bdbbac1e106736ad uses this
as a base to allow skins/extensions to define new OOjs UI themes.
resources/Resources.php
resources/ResourcesOOUI.php
includes/resourceloader/ResourceLoader.php
* OOjs UI resource module definitions are moved back to their rightly
place in Resources.php. They are again (almost) normal and static.
* Theme-specific logic is now handled by the module code, definitions
only specify 'themeScripts'/'themeStyles'/'themeImages'.
* ResourcesOOUI.php is deleted and no longer loaded by ResourceLoader.
includes/resourceloader/ResourceLoaderOOUIFileModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Glue code previously existing in ResourcesOOUI.php now lives here.
* Use the ResourceLoaderOOUIModule trait to avoid code duplication.
Change-Id: I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc
FloatingMenuSelectWidget has been deprecated in OOUI, moving to the
MenuSelectWidget widget instead.
Change-Id: Id4e5e4c551d50242ce19837c2e958b9773139906
* Add two DateInputWidgets to Special:Contributions, one for start and
one for end
** If start input is empty but end input is not, display edits up to end
input, and vice versa
** If both inputs are specified, display edits between the two dates
** If both inputs are empty, no date range is used
* Legacy options (year=/month=) are converted to use for the end
timestamp, so URLs with them should still work.
* Unit tests!
Bug: T120733
Change-Id: Id15f2b2ce2954fe98dfbbb7b0e86c0e4e5713f5e
Module 'mediawiki.page.watch.ajax' requires a dependency to module
'mediawiki.page.startup' because 'mediawiki.page.startup' creates the object
mw.page and 'mediawiki.page.watch.ajax' requires this object.
This dependency got lost in 06a0dec057.
Bug: T114288
Change-Id: Iebfda85c77eaf6bb19d2ae755813b1c36a95dac8
(cherry picked from commit ef456a7805)
This avoids the public method mw.util.init().
Add a noop function and a deprecation warning to mw.util.init().
The dependency to module 'mediawiki.page.startup' is not necessary anymore
for using mw.util.$content.
Change-Id: Ib8ca3f9afa43de0ff0bb87569dd2ddfddf2a69b8
The module 'mediawiki.page.patrol.ajax' does not need a dependency on
the module 'mediawiki.page.startup'.
Change-Id: I2619a0709b93c26a8b3906273b4d5a988230d662
No longer hide the button when the menu is empty, but instead
show the placeholder item when the *model* is empty.
Bug: T164861
Change-Id: I96e5e375de5f35946663042f6731d7b69e53308b
* Load module 'mediawiki.action.view.postEdit' only when needed.
* Transfer message key via JavaScript config variable wgPostEdit.
* The response is maked as not-cachable to prevent that other users get the
post edit message.
This change redefines the global JavaScript variable wgPostEdit from true
to a string and set it on server-side.
Bug: T164148
Change-Id: Id780bc280ce4a2fa4606141419932b7dcd45157b
* Remove HTML template
* Add mw-notification class and dependency
* Fix variable scoping issues so firing two notifications
doesn't cause one to become stuck
Bug: T58313
Change-Id: I9a702d23a8a9b5cc098cbb413213d73813bec097
Preparing for adding other types of items than filters (namespaces,
users, tags, etc) this commit creates base classes for the model
and relevant widgets and extends Filter* from them.
Bug: T159942
Bug: T163521
Change-Id: I61c88a1f14a3ca9d91aa831187eda156468a6591
Loading Special:Block/<your own name> shows "Confirm block", but
this then becomes bold a second later. This is because the styles
are part of 'mediawiki.special.block' which also contains JavaScript
and is loaded with addModules().
Move the styles to mediawiki.special.css instead.
Change-Id: I1c47256227603a6cde36238fdd7e11205d9494ec
The new widget in OOUI is more stable and easier to manage,
and gives us a few features that we were missing, like
arrow behavior in the menu.
Depends on OOUI release 0.21.0
Bug: T162829
Bug: T159768
Bug: T162709
Bug: T162917
Change-Id: I42be0691304b1e93b4e9c02eba2e3a724a5ffd67
Depends-On: Ic216769f48e4677da5b7274f491aa08a95aa8076
Source code:
https://code.jquery.com/jquery-3.2.1.jshttps://code.jquery.com/jquery-migrate-3.0.0.js
Documentation:
https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/https://jquery.com/upgrade-guide/3.0/
This is not a breaking change because jQuery Migrate covers
all breaking changes.
However some extensions (especially unit tests) may've relied
on undocumented behaviour. For that reason, and due to unresolved
upsteam issues this is still behind a feature flag for now.
It is true by default to ensure this has wide exposure to discover
issues as quickly as possible. If this is not resolved before
the end of the 1.29 release cycle it should be turned off again.
Bug: T124742
Change-Id: I3c3dedaa9a9d449eaa2b7e5d24b4540e7fa421c0
Keeping only importScript and friends and addOnloadHook for now.
Inline wikiUrlencode logic so that the dependency on mediawiki.util can be
removed, which caused significant performance overhead (See I54f087655e1c).
Follows-up:
* 68fae478a8 (1.22; deprecation warnings for ua vars)
* ec69391a4f (1.22; deprecation warnings for jsMsg)
* fcf4934a52 (1.23; deprecation warnings for the rest)
The following have been deprecated since either 1.17 or 1.18. Deprecation
warnings were added in 1.22. Most of these variables have also been replaced
with dummy placeholders in 1.22 so that calling code is silently disabled
instead of causing cascading failures into other code. Anything still using
these variables to date has been broken since at least April 2013.
* User-Agent variables:
is_gecko, is_chrome_mac, is_chrome, webkit_version, is_safari_win, is_safari,
webkit_match, is_ff2, ff2_bugs, is_ff2_win, is_ff2_x11, opera95_bugs,
opera7_bugs, opera6_bugs, is_opera_95, is_opera_preseven, is_opera, ie6_bugs.
(deprecated since 1.17; warnings and hardcoded to false since 1.22)
clientPC
(deprecated since 1.17; warnings added in 1.22)
* DOM manipulation:
changeText, killEvt, addHandler, hookEvent, addClickHandler, removeHandler,
getElementsByClassName, getInnerText.
(deprecated since 1.17; replaced with no-op warning dummies in 1.22)
* Checkbox utilities:
setupCheckboxShiftClick, addCheckboxClickHandlers.
(deprecated since 1.17; replaced with no-op warning dummies in 1.22)
* Classic toolbar utilities:
mwEditButtons, mwCustomEditButtons
(deprecated since 1.17; replaced with no-op warning dummies in 1.22)
* Misc utilities:
- injectSpinner, removeSpinner, escapeQuotes, escapeQuotesHTML, jsMsg
(deprecated since 1.17; replaced with no-op warning dummies in 1.22)
- addPortletLink, appendCSS, tooltipAccessKeyPrefix,
tooltipAccessKeyRegexp, updateTooltipAccessKeys
(deprecated since 1.17; warnings added in 1.22)
Bug: T122755
Change-Id: I7f9f61ea81ad1efa0b5cff79b5e5f4bbe2d401fe
The CompletenessTest was my attempt at measuring a basic code coverage
using run-time inspection instead of static instrumentation.
Originally added in 540419a82e (2010; MediaWiki 1.17).
It was never finished, remained fairly buggy and disabled by default.
It is also no longer used anywhere.
Bug: T155194
Change-Id: I26e7466426dddb43596f402e31005a89060c1b96
It makes no sense to add a tooltip to a button that already
has text, especially if the tooltip text is (almost)
the same as the button text.
This reverts commit 31047fb1bf.
Change-Id: I2f9c819a85fc05f37c7c0c5acf2d72319bdb0d76
The button changes state between 'restore default filters' and
the trash icon which is to remove all selected filters.
The title for the button should also change accordingly.
Change-Id: I9070f0c4959f5c7c97d57d943103ae2baf89d6d2
Redundant with CSS 'text-overflow: ellipsis', which is already applied.
Aside from ellipsis overflow, autoEllipsis() was also serving as indirect
caller of `highlightText( option.matchText )` and `attr('title')`,
which we want to keep, so leave that in its place.
Bug: T160804
Change-Id: I550183750d66d769cc9c960150a2349d1b9181aa
Tooltips represent the state of the filter, whether it is
conflicted, included, or fully covered.
If none of the above, tooltip message falls back on displaying
the description of the filter.
Bug: T156864
Change-Id: Ic97c7c6aae78bb6ddf51f0294eeae4b7f86a1a1d
It was originally introduced for jquery.searchSuggest, which hasn't
used this since 2014 (56a4aff8ca) when it was removed for
performance reasons (T61172) in favour of CSS text-overflow.
Deprecation is done the same way as for 'jquery.arrowSteps'.
Bug: T160804
Change-Id: Ib7b37b94200a8802de9d98581d3cb42df6e5ba17
Some used a string value, others an array with 'message' property.
Standardise on the string value, which seems more intuitive.
Change-Id: I5caead7b7017d2bad660db02fb45a54a26bf3728
Was only used by UploadWizard, and no-where else in Wikimedia Git.
UploadWizard has its own copy as of last year. (T144974)
Change-Id: I3d426f67f8ba061d10434469f261cb725bd672d6
The block cookie was being replicated to localStorage in an attempt
to make it harder for users to get around the block by deleting the
cookie (and changing IP addresses).
This whole setup was hard to test, had a few bugs (e.g. the localStorage
value would never expire), and given that it is a minor improvement
over just a plain cookie, it is now being removed. The cookie is only
intended to stop casual block-evaders (other users will get around it
by deleting the cookie or using incognito mode) and so it is not felt
worth having the extra complexity that will only guard against people
who know to remove cookies, not use incognito mode, and yet don't know
to remove localStorage.
Bug: T152952
Change-Id: Ifb06dc2390f4d648d7fcb39e30267de5eddc6941
Use the cancreateerror returned from list=users&usprop=cancreate for
username validation.
Use the new action=validatepassword to validate entered passwords.
This also injects the resulting errors in the style of HTMLForm's field
validation rather than at the top of the form.
Change-Id: Ie8c1270eb605367556fe36b0b2080eb3f957dc54
These are a few minor fixes to improved the
UX of the new sister search sidebar.
- Making the link color on sister search results blue
- Fixing the order of the multimedia search results widget
- added a more explicit 'more results' message instead
of the current '(more)' message.
- aligning the top of the sidebar with the top of the regular
search results.
- fixing a typo in the multimedia widget.
Bug: T158935
Change-Id: Iaae603cc217b7847bebfa61b050b7c86bdd19f14
Generate old RC, Related changes (it was already displayed and working
on 'Related changes' before this change), and Watchlist/etc. and data
for new UI from back-end.
This moves everything used for defining the old (unstructured) and new
(structured) filters into unified objects, ChangesListFilter and
ChangesListFilterGroup (and sub-classes).
This includes the query logic (see below) and logic for adding
CSS attribution classes.
This is a breaking change (for subclasses of ChangesListSpecialpage)
due to the signature (and name) change of buildMainQueryConds and
doMainQuery. An alternative that I don't think is a breaking change
would be to put the filter->DB logic in runMainQueryHook, but then it's
doing more than just running a hook.
This is because it used to only build $conds here, but it's clear from
filterOnUserExperienceLevel filters need more than this. I added all
the DB parameters from the hook, but this could be debated.
I have an checked and fixed the WMF-deployed extensions affected by
this.
Other than that, there should be full back-compat (including legacy
filters not using the new system).
* add hidepatrolled/hideunpatrolled to new UI.
* Move userExpLevel from RC to ChangesListSpecialPage. Although for
now the structured UI only displays on RC anyway, when it displays on
watchlist, it seems we'll want userExpLevel there.
Change this to make 'all' exclude unregistered users.
* Don't have front-end convert none-selected to 'all' on string_options.
* Needs the hideanons/hideliu special redirect to be done before this
is merged (T151873)
Bug: T152754
Bug: T152797
Change-Id: Iec2d82f6a830403d1c948a280efa58992e0cdee7
Currently, module 'jquery.makeCollapsible' is loaded on all pages
regarless of whether the page contains any collapsible elements.
It is required via 'mediawiki.page.ready'. Change this to lazy-loading
when needed only.
However, this lazy-load is discovered very late (after page ready,
after modules ready). To avoid regressing UX with an annoying reflow
of content and a very late hiding of collapsed elements, still
enqueue it in the main module loader by default on pages that
contain collapsible content server-side.
Bug: T159911
Change-Id: I4703ecd52d2d60207ba39108a4b3ef4aa1570965
Ie9a4612de changed it to use mw.storage, but didn't update the
dependencies. So if nothing else happened to load mediawiki.storage
already, it blows up.
Change-Id: Id276a29d914dacd1d176469db542b41ce6498ea1
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
Let there be highlight! and there were highlights
And RCFilters separated the highlight from the darkness
And it defined highlights as five colors
The lights are called yellow and green, and the darks red and blue
And there were colors and there were circles; one highlight.
This is the commit that adds highlight support for filters both in the backend
and the UI. The backend tags results based on which filter they fit and the
front end paints those results according to the color chosen by the user.
Highlights can be toggled off and on.
Also added circle indicators to the capsule items and each line of results
to indicate whether the line has more than one color affecting it.
Bug: T149467
Bug: T156164
Change-Id: I341c3f7c224271a18d455b9e5f5457ec43de802d
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
Selecting/unselecting a filter now refreshes the results list using AJAX.
Also added pushState to update the URL, and popstate handling
to make the back button work.
Bug: T153949
Change-Id: I8c1ec557ccfe4b1d20aaaab3ef0d3182a1993f24
Languages and locales now with support:
* aeb-arab
* dv
* fy
* gd
* jv
* kk-cyrl
* ky
* lo
* ms
* pa
* se
* si
* ss
* sw
* te
* zh-hk
Skipped languages because we don't support them in MW:
* ar-ly
* en-ie
* en-nz
* es-do
* fr-ch
* me
* tlh
* tzl
Change-Id: I7f89569c6ee6640d368af1378e84c5a9e725da0d
Transform the groups Object to a full data model that
handles events, and connect the FilterGroupWidget to
its model for responding to these events.
Bug: T156533
Change-Id: Iebde3138e16bac7f62e8f557e5ce08f41a9535cb
New widget and html form field, which allows selecting multiple
users using convenient single-line input (CapsuleMultiselectWidget)
Bug: T131492
Change-Id: I7b6ffe7fb47e0a7083e2a956156ab0f142444398
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
This is a bit hacky because the filter name needs to be inferred
from the class on each span, and because the separators aren't
wrapped.
Change-Id: Ib39ad435d3b48fa38533926e4ab49942c3bd5d6f
I9c24a230 added a box with a JSON-formatted version of the request
parmeters, saying "In the future we can provide more formats via a
dropdown". That future should have been then. It is now.
Beyond simply making it possible to select the format via a dropdown,
this change adds a JS hook, apisandbox.formatRequest, to allow adding
new formats from extensions, gadgets, and site scripts instead of
requiring them all to be added to core.
Change-Id: I20b093e0891f36cb3f1faa3eb3d6aed0f17b6b7d
See the task, this was probably entirely my fault not having
looked at this more carefully. Technically the change is ok,
however, it seems to doesn't make much sense in combination
with the Reason dropdown box.
This reverts commit faab2411c2.
Task: T34950
Change-Id: I1eeb9c68ff0db20d29e7d5f0fb18f0bfa3224416
There is no point in keeping these api-error- messages.
They were originally introduced in UploadWizard, then moved
to core, where nothing else (apart from some in BookletLayout)
uses them. They are mostly duplicates of other messages in
core, and these are very easy to miss when updating a message
in core.
Instead of building the messages on the frontend, we're much
better off requesting a parsed error response from the API
right away. This also lets us get rid of sime hacks (e.g. for
AbuseFilter)
And then a few other api-error-* messages have been removed
in favor of their alternatives (which are also used elsewhere)
And stashfailed is not a warning. Maybe it was at some point,
but stashfailed now dies with an error.
Bug: T47843
Change-Id: I41d88e2aad308a1fecd10d97085345a17d0c3603
No longer needed after I08244addcf9b6eb96137895f28e7b750914fef5c.
Also remove datetime.js from mediawiki.htmlform module.
Change-Id: Ic2410c689de3f70f573fa1c71456e6d3f334f80b
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
In the future we can provide more formats via a dropdown
(e.g. PHP object notation, MW formatted javascript, ...)
but for now JSON is a very commonly used format, and easily
adaptable.
Bug: T130501
Change-Id: I9c24a2309d2474e9543e2b577fe90d160a1b6cbc
Introduced in 1f987fb5ee.
This is quite dated and obsolete since then. The current code in
the 'mediawiki.searchSuggest' and 'jquery.suggestions' works fine
in all currently supported Grade A browsers (per startup.js).
Change-Id: I6d281459e230fa6a2971a31314f9e963dc83ff2b
This makes the code for processing JSON files with
grammar transformations reusable by different languages
and applies the same logic to Russian and Hebrew.
It will be done to other languages in further patches.
This patch is not supposed to change any functionality,
and the tests are intact (except a comment in the test
for Hebrew - the class doesn't exist any longer).
PHP:
* Move the JSON grammar transformation data processing logic
from LanguageRu.php to convertGrammar() in Language.php.
By default all these data files are supposed to be
processed identically, so the code should be common.
If there is no JSON data file, nothing new happens.
* LanguageRu's own convertGrammar() method is removed.
* The LanguageHe class is removed, now that all its functionality
is handled by generic JSON data processing in the Language class.
LanguageHe.php file is removed from the repo and from autoloading.
JavaScript:
* Move the JSON grammar transformation data processing logic
from ru.js to mediawiki.language.js.
* JavaScript grammar code files he.js and ru.js are removed
from the repo and from Resources.php, because all the data
is in JSON, and the default logic in mediawiki.language.js
works for both languages.
Bug: T115217
Change-Id: I5e75467121c3d791bb84f9e6fdfcf07c1840f81a
People don't seem to like having a dialog to ask for confirmation to set all
pages to visited in the watchlist, and the PHP server-side reset
functionality doesn't ask for a confirmation anyways.
Bug: T153438
Change-Id: I92aa3c0670925efc691d8bdba2c1c503e17ddb8c
When the "mark pages as visited" is clicked, a dialog appears,
asking for confirmation. On confirmation, an API request is sent
to mark all pages as visited, and all unvisited watchlist entries
are changed to appear visited.
Based on a userscript by User:NQ (from English Wikipedia)
https://en.wikipedia.org/wiki/User:NQ/WatchlistResetConfirm.js
Bug: T150045
Change-Id: I45fb02a1edc1b0331925e9a244a2455f86ad3886
This makes the watchlist js load all the time, instead of only
if the auto-reload preference is set, so we can put other things
in the same js module.
Bug: T150045
Change-Id: Ib8acca39593fe3d2369dc3187a9a55413553843d
* Use errorformat for action=login Failed responses in non-BC mode.
* We removed 'messageHtml' from action=rollback's response on error, but
left it for success. Remove it there too, it's even less useful.
* We changed action=watch's reporting of errors, but left the
mostly-pointless reporting of "success" UI messages. These should be
handled on the client side.
Change-Id: Ia6c402a4254fbacf4c2c3f125ce8bf0bcc71e509
All A-graded browsers now supports JSON so skip the
JSON polyfill. Krinkle investigated the current
status for 3 months on Wikimedia traffic (T141344#2784065)
with support being nearly 100%.
Bug: T141344
Change-Id: I8280faf1cbcd876ead2dafae4347b7d46e3e2acb
Send a cookie with blocks that have autoblock turned on so that
the user will be identified to MediaWiki and any IP they try
to edit anonymously from will be blocked, even without logging
in to the originally blocked account. Additionally, the block
info is stored in local storage as well as an even stronger
deterrence.
Note: this is meant to deter normal vandals, i.e., not attackers
who know what cookies and local storage are and will be actively
removing the cookie.
This feature is disabled by default, and can be enabled with the
new $wgCookieSetOnAutoblock configuration variable (by setting
it to true);
The cookie will expire at the same time as the block or after
$wgCookieExpiration (whichever is sooner).
Bug: T5233
Bug: T147610
Change-Id: Ic3383af56c555c1592d272490ff4da683b9d7b1b
In action=help this is reflected by the "Type" field, but that field
isn't displayed in ApiSandbox.
Change-Id: I7e491acc8ba7fdc3463f3cf1656b13fb3949d7d3
To accomplish this, the responsibility for setting the HTTP status code
in the response is moved to ApiFormatBase.
This also adds a line to the pretty-printed response and to ApiSandbox's
output to indicate the status that would be used.
Bug: T150344
Change-Id: Iaf0698ee1b93565d9b02b5a9aa8f93ceb135658b
It's a special page and only uses mobile vetted code
so completely fine to load this on mobile
That said the visual display needs a lot of work but that
can be remedied in a follow up.
Bug: T148049
Change-Id: I2a8424e7c348bd5283aba99d1a81bb259d7e54c5
