Page MenuHomePhabricator

Abuse filters cannot be edited without javascript
Closed, ResolvedPublic

Description

I am an abuse filter editor on the French Wikipedia. When I open a filter such as https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Filtre_antiabus/1 without having JavaScript enabled, the content of the filter is now displayed in a <div>, and thus cannot be edited. A few days or maybe weeks ago, it was in a standard <textarea>. This change makes the extension unusable without JavaScript. Is it possible to keep this working without JavaScript?

Event Timeline

Huji triaged this task as High priority.Apr 15 2018, 10:50 PM
Huji added a project: CodeEditor.
Huji added subscribers: Daimona, Huji.

That is weird. AbuseFilter now uses CodeEditor, but CodeEditor is supposed to show you the textarea when JS is not enabled. Somehow, it doesn't (the textarea is there if you look at the page HTML, it is just not visible).

@Huji Actually, this isn't supposed to happen in AF. A simple fix I can imagine is to generate the page with the textarea always visible and the Ace div hidden (if there). Then, from JS, if Ace is enabled switch visibility for them when initializing.

Aklapper added a subscriber: Nirmos.

@Nirmos: I don't think this is Accessibility by its definition

I'm currently working on this. Apart from the philosophical matter itself of disabling JS, AF strongly relies on it. With JS disabled, for instance, you can't perform syntax checks, the action checkboxes are all expanded and you can't use /tools.

Change 426942 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Use the old textarea if JavaScript is disabled

https://gerrit.wikimedia.org/r/426942

I also think that Javascript is such an integral part to AbuseFilter (and MediaWiki as a whole) that supporting noscript is not the best idea. Some of the other existing functionality in AbuseFilter (such as the form that let's you debug code, the form that let's you re-add "autoconfirmed" status to a user, etc.) already rely on JS. So I am leaning towards declining this request altogether and officially stating that AbuseFilter requires JS.

It makes me wonder if MediaWiki itself officially anounces that it requires JS or not. I couldn't find the answer by a simple search; let me go ahead and ask it on mediawiki-l

I also think that Javascript is such an integral part to AbuseFilter (and MediaWiki as a whole) that supporting noscript is not the best idea. Some of the other existing functionality in AbuseFilter (such as the form that let's you debug code, the form that let's you re-add "autoconfirmed" status to a user, etc.) already rely on JS. So I am leaning towards declining this request altogether and officially stating that AbuseFilter requires JS.

It makes me wonder if MediaWiki itself officially anounces that it requires JS or not. I couldn't find the answer by a simple search; let me go ahead and ask it on mediawiki-l

MediaWiki goes to great lengths to ensure that no-JS works, and AbuseFilter should as well. If other interfaces don't nicely degrade when JS isn't available, that's a bug. There's some good information at https://www.mediawiki.org/wiki/No-JavaScript_notes on why it's important to support, and how best to support it.

Huji removed a project: Patch-For-Review.

Change 426942 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Use the old textarea if JavaScript is disabled

https://gerrit.wikimedia.org/r/426942

Change 428563 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@REL1_31] Use the old textarea if JavaScript is disabled

https://gerrit.wikimedia.org/r/428563

Change 428563 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@REL1_31] Use the old textarea if JavaScript is disabled

https://gerrit.wikimedia.org/r/428563