Extension talk:MobileFrontend

Conflicts with Mediawiki 1.43?

Hi - I recently upgraded two wikis from 1.42.1 to 1.43 and it has somewhat deprecated the functionality of MobileFrontend: firstly, the “collapsing sections” does not work: the sections present as collapsed and unexpandable (which makes the mobile view a bit useless!).

Secondly, the editing window is a bit deprecated and shows an edit window that is an odd hybrid of the mobile edit window and the desktop edit window. It works after a fashion though. Any idea what might cause this? what additional information would you need? MF worked perfectly for me in 1.42.1 and I haven't changed anything else as far as I know.

Browser console says the following:

load.php?lang=en&mod…a&version=zyfu3:507 Less_Exception_Compiler: variable @width-breakpoint-tablet is undefined in file /home/root/public_html/extensions/MobileFrontend/resources/mobile.startup/Overlay.less in Overlay.less on line 270, column 29
268| }
269| 
270| @media all and ( min-width: @width-breakpoint-tablet 
) {
271| 	.overlay {
272| 		.panel {
273| 			padding-top: 12px;

Would it be useful to include the whole backtrace?

Thanks ElectricRay (talk) 12:01, 29 January 2025 (UTC)

Conflicts with Mediawiki 1.42.3?

I have a similar problem: Upon upgrade to 1.42.3, everything mobile fails completely. The error message is "Call to undefined method MediaWiki\Output\OutputPage::setTarget()". setTarget is called from MobileFrontend/includes/MobileFrontendHooks.php(217), inside method OnBeforeInitialize.

I'm running MobileFrontEnd 2.4.1, which this web page says is the most recent version. Also, the release notes for 1.42 say explicitly that OutputPage::setTarget() has been removed. So I wonder how ElectricRay can be running it at all! Could it have been put back for 1.43? I see nothing that indicates it has.

Any advice greatly appreciated.

--Larrydberg (talk) 18:08, 1 February 2025 (UTC)

I have also same problem as ElectricRay

Any help? collapsing sections frizzing and double arrow coming. 149.7.163.159 15:04, 6 March 2025 (UTC)

I found out Always expand sections of content pages by default is not on in default, but I don't still know why coming double arrow. 149.7.163.159 15:44, 6 March 2025 (UTC)

Detecting MobileFrontend for conditional JavaScript loading

We have JavaScript code at w:fr:MediaWiki:Gadget-CommonEdit.js (currently conditionally loaded by w:fr:MediaWiki:Common.js) that was originally designed for the regular editing interface, which was the only available option at the time. This code is relevant for all skins (including Minerva on desktop), but not for the MobileFrontend editing interface.

How, then, could we test if the current page is using the MobileFrontend editor to avoid loading the code in such cases? Ideally, this should be a simple test, performed without querying the DOM, and as early in the process as possible.

More generally, how can we determine if MobileFrontend is running on the current page? While there are many mw.config.get('wgMF...') configuration items, they are optional and subject to changes or removal. Unfortunately, there is no straightforward equivalent to mw.config.get('wgMFEnabled') that would reliably return true or undefined.

ping @Jdlrobson

Od1n (talk) 18:52, 11 March 2025 (UTC)

You are already checking if the editor page is presentin Common.js in this code:

if ( [ 'edit', 'submit' ].includes( mw.config.get( 'wgAction' ) ) {
}

I don't think this conditionally loading is working how you expect it to.

When I visit https://fr.wikipedia.org/wiki/Spain?action=edit the code seems to load, but doesn't do anything (just as it does on https://fr.m.wikipedia.org/wiki/Spain?action=edit#foo).

I would also suggest checking in the if statement for:

$( '#specialcharsets' ).length

You shouldn't need to detect MobileFrontend - really the code should be using clues on the page to work out if it should run at all. When progressively enhancing the page - your test should be for the element you are progressively enhancing. Jon (WMF) (talk) 20:00, 11 March 2025 (UTC)

• The code does work, basically it is for the dropdown below « Caractères spéciaux ».
• Just for notice, CommonEdit.js also does one small another thing : force IPs to preview before submitting (forcePreview() function at the beginning).
• Good point about progressively augmenting #specialcharsets (maybe not in the if as you suggested, but I see the point). Now that CommonEdit.js is almost exclusively about #specialcharsets (previously this file also had other purposes), we could probably make use of this approach.

Od1n (talk) 21:09, 11 March 2025 (UTC)

> The code does work, basically it is for the dropdown below « Caractères spéciaux ».

it doesn't work for either my staff account or personal account. There is no dropdown at the bottom of the page. Perhaps there's a preference that turns it on? Jon (WMF) (talk) 16:35, 12 March 2025 (UTC)

That's really surprising. I, along with many other users, have seen this dropdown consistently for decades without any interruptions. You're using the regular wikitext editor (not VE or the MobileFrontend editor), right? Does mw.loader.getState('ext.gadget.CommonEdit'); return ready as expected? Od1n (talk) 01:59, 13 March 2025 (UTC)