Your screenshots look as if the styles for the 'oojs-ui-widgets' module were not loaded. All of the visually broken widgets belong to that module (TabSelectWidget, ButtonSelectWidget, OutlineSelectWidget).
This is done for MediaWiki. The patch should be deployed to all Wikimedia wikis on Monday (wmf.5 has been delayed due to unrelated problems).
This is done for MediaWiki. I filed T195546: Run the maintenance script cleanupTitles.php (in dry run mode first) on all wikis after wmf.5 deployment about running cleanupTitles.php on Wikimedia wikis.
Thu, May 24
I was assuming classic desktop wikitext editor (and testing as a logged-out user).
So, to rephrase – viewing a URL like https://commons.m.wikimedia.org/wiki/User:Matma_Rex/sandbox?action=edit redirects to https://commons.m.wikimedia.org/wiki/User:Matma_Rex/sandbox#/editor/0 instead of loading the desktop wikitext editor.
There is a separate task about the broken text: T195525: MWExceptionRenderer.php doesn't always declare the encoding used.. It already has a patch pending, so in case another issue like this occurs, at least the error message will be displayed correctly ;)
Minimal test case:
A * B ** C * D
(For context, this is about the error message shown during recent database issues, T195520)
I am thrilled to report that Gerrit has fixed this at some point!
These look like the watchlist notification emails, so removing Notifications (a.k.a. Echo extension).
For future reference: we had issues with Safari not rendering the checkmarks in the past, but we worked around them: T89309: [Regression wmf17] Safari - cannot click in any check-box. Somehow the recent changes must have triggered a similar issue again (rGOJUec032ef96417: CheckboxInputWidget: Don't specify icon in CSS).
Tue, May 22
This was caused by us setting the value on all inputs when one of the inputs was changed, including re-setting it on the input being edited:
Could you, please, reallow cascade semi-protection,
This is probably no longer a problem?
Mon, May 21
This is excellent \o/
Sun, May 20
The page is currently sorted by file upload date (img_timestamp).
Sat, May 19
Screenshot (I've put no effort yet into tweaking the CSS):
Demo of highlights with holes using SVG clip-paths and masks:
No longer happening… probably was a browser bug.
I think we might not have recording equipment in this room :(
Fri, May 18
This is not lego messages or in fact our code at all. It's an override from https://en.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Tog-enotifwatchlistpages. I don't know why it was put there, I agree it is stupid.
Meh, I guess this is getting merged anyway. Please never use this module though. You're just asking for an unintentional OOUI change to break your thing.
It seems that AuthManager checks the user rights too stringently (when calling isBlockedFromCreateAccount()). In addition to checking whether the account creator can create the new account (AuthManager::checkAccountCreatePermissions()), it also checks whether the new account can create itself (CheckBlocksSecondaryAuthenticationProvider::testUserForCreation()). I think that is incorrect, but perhaps there is a reason for this (or perhaps it has always been this way, and you're in fact requesting a new feature).
Is this a regression? Why is it "unbreak now"?
Can you clarify what would you like the error message to explain?
Looks like Parsoid is marking up the first paragraph as part of the transclusion. This might be a bug in Parsoid or broken syntax in the infobox template (e.g. unclosed HTML tags).
If you try to insert a link anyway, it crashes VE. But does not show any error in the console.
Thu, May 17
MediaWiki uses the binary type for many text fields, but most of them contain UTF-8 text, so treating their contents as UTF-8 instead of binary data doesn't corrupt them. (Off the top of my head, the only columns that actually may contain binary data, depending on your configuration, are categorylinks.cl_sortkey and page_props.pp_value.)
Wed, May 16
Caused by https://gerrit.wikimedia.org/r/#/c/428136/ in OOUI v0.26.5.
So I think this was only a problem in Firefox 59. I'll close this task, but if you notice this again in another browser, please reopen. :)
I think this is a problem with your export method. The data in fields like ref_id is actually raw binary data, but it looks like your export tool tried to interpret is at UTF-8 (decode and re-encode it). It is not valid UTF-8 text, so some of the bytes were replaced with '�' (U+FFFD replacement character), which obviously corrupts the data. If you managed to import it, you'd probably find your Flow threads to be inaccessible.
I am not sure if this would be desirable.
Looks like this check happens in WikiPage:
// Mark as patrolled if the user can do so $autopatrolled = $wgUseRCPatrol && !count( $this->mTitle->getUserPermissionsErrors( 'autopatrol', $user ) );
Title::getUserPermissionsErrors() calls Title::checkUserBlock(), which calls User::isBlockedFrom(), but only for $action == 'edit' || $action == 'create'. We should probably add 'autopatrol' to that list.
Setting a z-index will not help, because the Vector skin is constructed so that elements inside the content (.mw-body-content) can not obscure the skin interface elements (like the menus), because it creates a stacking context (with position: relative; z-index: 0;).
Tue, May 15
The patch will be deployed to Wikimedia wikis this week per the usual
schedule (Tuesday-Thursday), but note that the first-letter data is
additionally cached for up to a week, so it might take a bit longer for the
issue to be fixed. I'll keep this task open until I can verify the fix.
Mon, May 14
Yes, the patch there fixes this as well.
I investigated today why this happens:
- During VisualEditor's initialisation, <div id="mw-content-text"> is temporarily hidden while its contents are rearranged
- On category pages, VisualEditor initialisation happens a bit differently so that the list of pages remains visible – in particular, the editing surface is inserted inside the <div id="mw-content-text"> rather than next to it (DesktopArticleTarget#getEditableContent)
- When CodeEditor syntax-highlighting initializes (updateDisplayIfNeeded()), on category pages the editing surface is inside the hidden div, and so CodeEditor doesn't render it
- Then the div is shown again and the incomplete syntax-highlighting editing surface appears (looks like invisible text)
Thu, May 10
This works correctly these days: