Follow-up: works on 1.45 on Mirabeta. Whatever was causing the issue originally went away.

Backtrace from @SomeRandomDeveloper in https://issue-tracker.miraheze.org/P567

@stjn I believe it was you who suggested reporting this on Phabricator on Discord since the username matches your profile.

As a workaround, the url can be inserted in the form of //static.wikitide.net.... Dropping the protocol will prevent $wgAllowExternalImages from touching it, but the url is still recognized by WikiSEO and by some applications (discord was okay with it).

Downstream: https://issue-tracker.miraheze.org/T13802

I'm not sure why 320px is the center of the argument here. I feel like I made some good points independent of the exact size of the mobile screen (i.e. the padding used by other responsive skins and the need to have more space available for content on mobile). Regardless, I updated the original task description and changed 320px to 400px (along with all the screenshots).

I tried some other widths. Vector 2022 uses 1.5rem padding for screen widths 1100px and below. Using the same padding for 400px and 1100px width screens does not seem like a good idea to me and I don't think any other major responsive skin is doing this. Besides 0.45em and 1em, there's Fandom which uses 0.75em and Citizen which uses 20px=1.25em, and Citizen's spacing also seems awfully large to me.

Which hardware is this? I don't think we want to spend a lot of effort on such extreme screen widths.

Yeah that does seem to be the case. I switched TemplateStyles to the master branch and, after dropping the MW 1.45 version check, CodeMirror functions correctly for sanitized stylesheets.

Thanks for the suggestion. It did not make a difference on my end since codemirror still refuses to work with templatestyles stylesheets and scribunto.

I noticed that mw-body-header already has display: flex, so what is preventing us from setting flex-wrap to wrap under narrow screens?

Thanks for the suggestion. I modified $wgCodeMirrorContentModels to include more content models. css and javascript worked and the editor used CM6, but Scribunto and sanitized-css did not. I got the following error for both sanitized-css and Scribunto.

Warning: [CodeMirror] Unsupported content model sanitized-css [Called from MediaWiki\Extension\CodeMirror\Hooks::loadCodeMirrorOnEditPage in /var/www/mediawiki/extensions/CodeMirror/includes/Hooks.php at line 220]

Of course, if I remove these content models from CM's configuration, I get the plaintext input box again instead of the old CodeEditor.

Forgot to note: this also affects Lua modules and javascript pages, which are handled by CodeEditor but would become plaintext editors after enabling "Improved Syntax Highlighting".

Any updates on this? Moving the edit button's position in the DOM up so that it is before the description and then making it float: right should be a quick and easy solution? This button is small enough that usual concerns of float don't apply. Plus, users will be using mobilefrontend on narrower screens.

AFAIK there is no fix for this. Your best bet is to disable this extension and write your own dark mode CSS. You can also use the Theme or ThemeToggle extensions to allow switching between multiple themes.

Thanks @Samwilson. Looks like this is all good. Just need to wait for the patch to reach downstream.

@Jdlrobson-WMF I uploaded a patch for MinervaNeue as well. Minerva's CSS is a bit different, but I think the outcome is the same. The extra gray background mentioned in T361838 should be gone without compromising the scrolling behavior for larger tables.

In T402066#11104680, @Jdlrobson-WMF wrote:

@lihaohong the code serves both mobile and desktop and I don't believe fit-content has any effect there.

In particular, width: fit-content gets overridden by max-width: 100% with the screen is narrow, so I don't understand why this needs to be closed. It should be a strict improvement over the current solution.

The proposed fix does not compromise responsiveness in any way. It simply removes the problematic borders on the right.

Looks like the CSS was added as a result of T330527. I'm surprised it passed all the quality control steps considering how it breaks smaller tables on narrower screens.

It probably has to do with the following js. It doesn't do anything with client-darkmode if the user is anonymous. @Kizule would it be fine to execute the if ( darkMode ) statement for both anonymous and logged-in users? This change works on my local testing environment, but I'm not sure if the code is the way it is for some other reasons.

if ( mw.user.isAnon() ) {
        // If the user is anonymous (not logged in) write a cookie
        mw.user.clientPrefs.set( 'skin-theme', darkMode ? 'night' : 'day' );
} else {
        // If the user is logged in write with API to user settings
        new mw.Api().saveOption( 'darkmode', darkMode ? '1' : '0' );
        if ( darkMode ) {
                docClassList.add( 'skin-theme-clientpref-night' );
                docClassList.add( 'client-darkmode' );
                docClassList.remove( 'skin-theme-clientpref-day' );
        } else {
                docClassList.add( 'skin-theme-clientpref-day' );
                docClassList.remove( 'client-darkmode' );
                docClassList.remove( 'skin-theme-clientpref-night' );
        }
}

Looks like this is the offending table name.

((SELECT cst_c_comment_page_id AS `union_page_id` FROM `cs_comments` ) UNION (SELECT cst_r_reply_page_id AS `union_page_id` FROM `cs_replies` )) AS union_table

As far as I can tell, extractTableNameComponents checks whether there is a quotation mark in the string. If there is, it'll panic an throw the exception seen here. The backticks (`) are the culprit.