Steps to reproduce:
Expected (and this did work before 1.29.0-wmf.18, though I don't see any change): CodeEditor is disabled.
Actual: It is enabled, though mw.user.options.get('usecodeeditor') correctly gives 0.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Check for numeric 0 when checking 'usecodeeditor' pref in JS | mediawiki/extensions/CodeEditor | master | +2 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Anomie | T161875 CodeEditor is always enabled when starting an edit on a page containing code | |||
| Resolved | TheDJ | T162877 CodeEditor default changed if you have never used the toggle |
What's going on here is a bit involved.
To start, MediaWiki's user preference database storage stores only strings. If you try to put in a number or a boolean, it gets converted to a string. But this only happens for preferences that are actually stored in the database, preferences at their default values might be returned as numbers or booleans. See T54542: User preferences are inconsistently stored (bool/int as default, string for overrides) for discussion about fixing that.
Sometime last year, rMWf536c780eb9d: Database: Behave correctly when inserting booleans changed how booleans are sent to MySQL. Previously, it just used PHP's default casting, which turns true into '1' and false into ''. That fails when MySQL's strict mode is enabled and you're trying to insert into a tinyint(1) field because in strict mode the empty string isn't allowed to be converted to a number.
But this had the side effect that boolean user preferences started being stored as '0' for false instead of ''. That's fine for PHP since it considers the string '0' to be falsey, but JavaScript considers it truthy and so various scripts were breaking. Thus, rMW40f89f230ecc: Decode '0'-valued user options to integer 0 was done to return user preferences with the value '0' as numeric 0 instead, at least until T54542 can be fixed more generally.
And now we come to this bug: CodeEditor is explicitly setting its usecodeeditor preference to 0 and is strictly checking for '0' when fetching it back via the API, which now fails since the API has started returning the value as 0 instead. It's simple enough to fix, just check for both cases, and I'll submit a patch for that momentarily.
At a quick grep through deployed extensions, I don't see any other extension that is doing this, although it's certainly possible a less-quick search would turn something up. VE has some preferences that are used in a similar manner, but they're already checking it both ways.
Change 345831 had a related patch set uploaded (by Anomie):
[mediawiki/extensions/CodeEditor@master] Check for numeric 0 when checking 'usecodeeditor' pref in JS
Change 345831 merged by jenkins-bot:
[mediawiki/extensions/CodeEditor@master] Check for numeric 0 when checking 'usecodeeditor' pref in JS
Not sure if this is related, but on en.wp I see reports that the CodeEditor is suddenly disabled for them.
I see one such report at https://en.wikipedia.org/w/index.php?oldid=775086322#code_editor.3F, which seems to have turned out to be someone not knowing about the "<>" icon. Are there more reports?
yeah myself, just had the same experience on commons, de.wp, tl.wp. I never disabled code editor there, yet all of a sudden it seems no longer enabled by default.
Looking at it, It seems that by default, there is no user option registered: mw.user.options.get( 'usecodeeditor' ) returns null
We likely need to amend extension.json and add a "DefaultUserOptions": {"usecodeeditor":true} or 1, or whatevah :)