This feature never worked very well, and the original wish
https://w.wiki/7ZsE didn't ask for a 2010 editor solution, anyway.
Rather than have AbuseFilterBlockedExternalDomainsNotification linger in
an unstable state, we remove the code entirely.
Bug: T347435
Follow-Up: I7eae55f12da9ee58be5786bfc153e549b09598e7
Change-Id: I88e87c4e0a2968b892394461b1227f4d15938e8e
LibUp was getting caught out by the false-positive hit to
es-x/no-resizable-and-growable-arraybuffers, so doing a
manual fix to make progress.
Otherwise just whitespace changes.
Change-Id: Ibf20dd2d88613b0a74813c33239e7d0bac682b17
This leverages the new BlockedExternalDomains system that is now part of
AbuseFilter. It notifies editors in realtime if a link they add is
blocked. See https://w.wiki/7ZsF for more information.
BlockedExternalDomains is slated to have its own API tantamount to the
action=spamblacklist endpoint, after which case this code will need to be
updated. In the meantime, it's meant to serve as a minimal viable product
for the CWS 2023 wish <https://w.wiki/7ZsE> for wikitext users.
The new $wgAbuseFilterBlockedExternalDomainsNotification configuration
setting controls the availability of this feature.
A similar feature for VisaulEditor is tracked at T276857
Bug: T347435
Change-Id: I7eae55f12da9ee58be5786bfc153e549b09598e7
For example:
* Use the more meaningful str_contains().
* Add missing type hints.
* Make use of early returns/guard clauses.
Change-Id: Id150d1b17a80ea637a0639a8f2fd7fd017ad23b1
Increase default widths from `65%` to `90%` for the editor, notes,
description, group inputs.
Add `mw-abusefilter-edit-description-input` id to
`abusefilter-edit-description` TextInputWidget.
Bug: T294856
Change-Id: Ia9472298170740a39fd24864003b766078fcdfaf
Manually fixed as there's no fixer (and we're likely to bin this
rule upstream anyway as it has too many false positives).
Change-Id: Ia00113afa56af57c851ee8730760a60d6f858e7c
The check if $() found an element is not needed. Method calls will
operate happily on an empty result and do nothing, as expected.
Change-Id: I985ac4623d7968f037613174b14348885afed7d1
In the AF language,
```
foo := "abc
def"
```
declares a valid string with a linebreak inside. This wasn't previously
highlighted by ace, since normal rules are scanned line-by-line. The
code added here is essentially copied from the PHP highlighter [1],
whose rules should be almost the same as AF.
This new syntax also highlights escape sequences inside strings, e.g. in
"foo\\bar" see how the backslashes have a different color.
[1] - https://github.com/ajaxorg/ace/blob/master/lib/ace/mode/php_highlight_rules.js#L1058
Change-Id: Idb51001af00ff2ef118741cd686dc1adf19aebee
This patch adds a transparent HTMLForm field that can be used to insert
the edit box inside an HTMLForm, and updates /test and /tools to use
that. The field class, together with the other editbox-related classes,
is now in a dedicated namespace. A future TODO is making it a real
HTMLForm field.
Also improve a bit the form in /test: add section labels and
avoid reusing the same label message used on Special:AbuseFilter.
Bug: T261584
Change-Id: Ib74bb5fdba4f8476169b754030fce6d4f72ce65a
This commit introduces some boilerplate for emitting warnings from the
AbuseFilter parser, and also code for showing these warnings in the ace
editor. Adding new warnings should be as simple as appending to
AbuseFilterParser::warnings (and adding the relevant i18n).
Bug: T264768
Bug: T269770
Change-Id: Ic11021b379f997a89f59c8c0572338d957e089a6
The worker itself is essentially a wrapper around the
abusefilterchecksyntax API.
NOTE: As written in code comments, basically the whole
worker-abusefilter.js script consists of boilerplate code. You can
verify this by diffing this file and 6cb8a9cae1/modules/ace/worker-json.js
This means that there are only ~60 lines of code to review in that file.
Bug: T187686
Change-Id: I8950fcd5917ba226dda80b47b2bb713e685fad36
The editing view is currently full of tech debt, brittle and surprising
code and whatnot. It's basically a miracle if it works without problem,
and it'd be an even bigger miracle if you could change something there
without breaking anything.
For these reasons, and because that class must be refactored as part of
the upcoming overhaul, this patch adds a bunch of selenium tests to test
the main functionality of that page.
In particular, these tests cover all possible cases (each corresponding
to a data source) for which buildFilterEditor can be called, which FTR are:
1 - View the result of importing a filter
2 - Create a new filter
3 - Load the current version of an existing filter
4 - Load an old version of an existing filter
5 - Show the user input again if saving fails after one of the steps
above
Having automated tests to cover these cases means that we don't have to
manually test all the scenarios manually each time the class is touched.
Bug: T201193
Change-Id: I408e0a132905416effe0d6d6dc0921991edd66bd
This will prevent the labels from being squeezed under certain
conditions (e.g. if the interface is in Chinese). The labels are now
taking up more space for all languages, but that's not a problem because
we have plenty of space on the right.
Bug: T231962
Change-Id: I8569cc63c4116c3a8978258d5656c72fcf2552b0
The <pre> element is now hidden with CSS, and is only shown after the
user clicks the "Eval" button.
Moreover, make the button primary and progressive, as to indicate that
it activates the primary function of that page.
Bug: T253492
Change-Id: I300ce6ec0a84ea73025a5af9173024df7c291e03
* Update ESLint config with Selenium WebdriverIO test suite
* Update modules and Selenium pageobjects and specs per ESLint
requirements
* Update grunt-eslint package to 23.0.0 as required by
eslint-config-wikimedia 0.16.0
Bug: T254495
Change-Id: Ibfcf9115adedf9f2c3e7dac1ac626b41fc97b7c4
Using var_export for better visual effect, especially for arrays.
The result from /tools is much clearer and the 'wrong syntax' message is
a bit more explicative than before.
Bug: T190653
Bug: T239972
Change-Id: I79a17305c7f19f7900f896f895e9365bb5f2fd58
The editToken key of mw.users.tokens is deprecated since MediaWiki 1.27.
This commit resolves it for AbuseFilter.
Bug: T233442
Change-Id: I445313088cef40caf0d0695a64515cd16e83504d
Setting 'apiHookResult' results in a "successful" response; if we want
to report an error, we need to use ApiMessage. We already were doing
this for action=upload. Now our action=edit API responses will be
consistent with MediaWiki and other extensions, and will be able to
take advantage of errorformat=html.
Since this breaks compatibility anyway, also remove some redundant
backwards-compatibility values from the output.
To avoid user interface regressions in VisualEditor, the changes
I3b9c4fef (in VE) and I106dbd3c (in MediaWiki) should be merged first.
Before:
{
"edit": {
"code": "abusefilter-disallowed",
"message": {
"key": "abusefilter-disallowed",
"params": [ ... ]
},
"abusefilter": { ... },
"info": "Hit AbuseFilter: Test filter disallow",
"warning": "This action has been automatically identified ...",
"result": "Failure"
}
}
After:
{
"errors": [
{
"code": "abusefilter-disallowed",
"data": {
"abusefilter": { ... },
},
"module": "edit",
"*": "This action has been automatically identified ..."
}
],
"*": "See http://localhost:3080/w/api.php for API usage. ..."
}
For comparison, a 'readonly' error:
{
"errors": [
{
"code": "readonly",
"data": {
"readonlyreason": "foo bar"
},
"module": "main",
"*": "The wiki is currently in read-only mode."
}
],
"*": "See http://localhost:3080/w/api.php for API usage. ..."
}
Bug: T229539
Depends-On: I106dbd3cbdbf7082b1d1f1c1106ece6b19c22a86
Depends-On: I3b9c4fefc0869ef7999c21cef754434febd852ec
Change-Id: I5424de387cbbcc9c85026b8cfeaf01635eee34a0
Now it's always wider, and so is the "notes" field. Moreover, the
fallback textarea has the exact same size. Plus removed a parameter
which only made it hard to write a CSS rule for the textarea. Since the
textarea is generated by the same code, and we're always using it for
the same thing (filter syntax, regardless of the final goal), make it
always use the same name.
Bug: T230591
Change-Id: Ibb308e80d954c0e81aa09249c38c39572f157948
The VE save dialog will now only display a retry button for
AbuseFilter warnings, and not for errors.
Bug: T211241
Change-Id: I865e8078f79e6bbcb7134b11d5f834f84bb72589
Short explanation on phab. Ace stops at the first regex match, so we
must use a function to specify the token type.
Bug: T219593
Change-Id: If7e6e98de81ce7e1be334732518425c8115e4aea
Follow-up of I982d67aa62a899916a26452aceb9646df8c31232. The help text
was meant to be localized, and I probably forgot to do so in the
mentioned patch.
Change-Id: If394b02819911f9c97519b5c972977c38e6d83fa
The uppercase is just a leftover from a long time ago. Currently,
variables are case-insensitive, and we already perform a strtolower when
saving them. Since most parts of the code already use lowercase, the
uppercase leftovers only make it harder to grep the code to find
variables. As a bonus, make Ace recognize variables in a
case-insensitive fashion.
Change-Id: I72933fcc9952fc1aabf6464b2fc0b04ec39c024b
So that they're easier to read, and because readonly is semantically
more appropriate.
Bug: T217143
Change-Id: I76be8e7fb1cf46efd0c03cde74344be6cb2a0902
