While clicking on:

https://m.wikidata.org/w/index.php?preload=Wikidata%3ARequests+for+comment%2FExample&title=Wikidata:Requests_for_comment/Test&create=Create+a+request#/editor/all

It brings me to the first screen, then I don't have to click on anything at all and it switches to the inferior full screen mobile editor which automatically removes "{{RFCSubpage}}" and the category with no way to retrieve it.

In T213835#4881614, @DonTrung wrote:

While clicking on:
https://m.wikidata.org/w/index.php?preload=Wikidata%3ARequests+for+comment%2FExample&title=Wikidata:Requests_for_comment/Test&create=Create+a+request#/editor/all

Where does that URL come from? Which exact actions, starting on which page, create that URL above?
Please always provide a complete lists of steps to reproduce, step by step, as a list. See https://www.mediawiki.org/wiki/How_to_report_a_bug

@Aklapper, I did report further action, if you click on the link in the mobile editor it should remove all templates in the markup as could be seen in the attached screenshots.

A pardon, I missed the follow-up comment, I'll do it step-by-step below.

https://m.wikidata.org/wiki/Wikidata:Requests_for_comment

Then I create an RfC and land here:

https://m.wikidata.org/w/index.php?preload=Wikidata%3ARequests+for+comment%2FExample&title=Wikidata:Requests_for_comment/Test_report&create=Create+a+request#/editor/all

Then the page changes from one mobile editor with the right templates to an empty white page. Screenshots below.

First I try to create an RfC by using the standard "blue button".

First it brings me to the above page with all the right templates but then it (automatically) reloads 🔃.

Now all the pre-loaded content is gone, I have to manually add it again. This also happens with reporting vandalism on Wikimedia Commons and using standard messages.

I'm posting this here as my post (T246603) got merged into this one.

This is on mobile. If this parameter is intentionally not supported for mobile I would strongly suggest it be supported. The preload and preloadparams[] would work very well for the mobile JavaScript editing interface. The preloaded content isn't needless clutter to be stripped away, instead its intentional content that the user has elected to include to help minimize the amount of repetitive typing or flipping back and forth between windows for copying and pasting. People that don't want the parameter and what it brings wouldn't use it.

On my wiki, edits are made out in the field using a template that gets completed. Having an interface designed for the phone is great, but if it doesn't support what to us what are essential parameters, and if I can't disable the mobile JavaScript editing interface, then I would actually look at disabling MobileFrontend and MinervaNeue and struggle with the desktop version on the phone, but I hope I wouldn't have to do that.

This is causing lots of headaches over at the Community Wishlist Survey, where the input box on category pages (example) creates the form for the user to fill out. Is there not a cheap workaround? I do not recall seeing this issue in previous surveys (disregarding last year's, since it was a small-scale). I'm wondering if this a regression.

The cheapest workaround I can think of would be causing the inputbox (as defined on this template to include useformat=desktop in its generated URL (or inputs? I haven't verified that'd work). That'd force the edit form to be displayed as the desktop version.

I double-checked whether this was already supported, and no such luck -- we'd need to alter Extension:InputBox so that it knew about a new parameter.

It's also possible to add support for this to the mobile editor, of course -- that's just more work.

In T213835#7614317, @DLynch wrote:

It's also possible to add support for this to the mobile editor, of course -- that's just more work.

But definitely leads to a better UX. By the way, as far as I remember, preloads are planned in DiscussionTools – couldn’t part of the work reused between the two components?

But definitely leads to a better UX.

Oh, sure, it's just less helpful for the particular case of right-now where it's relevant for the current community wishlist work. For that prioritizing a quick hack might makes sense.

By the way, as far as I remember, preloads are planned in DiscussionTools – couldn’t part of the work reused between the two components?

I think we're debating how much DT should support preloads -- they're comparatively likely to come up for cases where DT's auto-signing isn't desired, for instance. That said, there's not any particular implementation crossover that'd be helpful for reuse; we'd just need to port over the behavior of the existing editors (mostly VE/NWE's specific API calls, I think).

In T213835#7615161, @Tacsipacsi wrote:

In T213835#7614317, @DLynch wrote:

It's also possible to add support for this to the mobile editor, of course -- that's just more work.

But definitely leads to a better UX. By the way, as far as I remember, preloads are planned in DiscussionTools – couldn’t part of the work reused between the two components?

Short answer: no. Longer answer: DT can borrow whatever it wants from MediaWiki, but not the other way around. Giving MediaWiki DT dependencies would be a terrible, terrible idea.

In T213835#7614317, @DLynch wrote:

The cheapest workaround I can think of would be causing the inputbox (as defined on this template to include useformat=desktop in its generated URL (or inputs? I haven't verified that'd work). That'd force the edit form to be displayed as the desktop version.

I double-checked whether this was already supported, and no such luck -- we'd need to alter Extension:InputBox so that it knew about a new parameter.

It's also possible to add support for this to the mobile editor, of course -- that's just more work.

$('#wikitext-editor')[0].value = $('#wpTextbox1')[0].value;

nailed it

nailed it

I feel obligated to point out that this would only function in source mode, so it working would be rather user-setting-dependent. I.e. more work needed.

In T213835#7824911, @DLynch wrote:

nailed it

I feel obligated to point out that this would only function in source mode, so it working would be rather user-setting-dependent. I.e. more work needed.

How do you switch between source and visual modes? It seems to possibly be OO.ui.ListToolGroup.super.super.prototype.onMouseKeyUp.call(this, e);, if I knew the values for this and e I could make it work I think.

In T213835#7824755, @AlexisJazz wrote:

Longer answer: DT can borrow whatever it wants from MediaWiki, but not the other way around. Giving MediaWiki DT dependencies would be a terrible, terrible idea.

It’s not DT and MediaWiki core, it’s DT and MobileFrontend. (What’s from core – the non-JS edit form – does already handle preloads.) It’s a common and perfectly acceptable practice that extensions depend on each other (it may even be an “optional dependency”, i.e. that MF uses the functionality provided by DT if it’s available, and provides a fallback if it isn’t, e.g. it redirects to the non-JS form). Core having hard dependencies on extensions is a bad idea, I know, but no one wanted here to do that.

In T213835#7825747, @Tacsipacsi wrote:

In T213835#7824755, @AlexisJazz wrote:

Longer answer: DT can borrow whatever it wants from MediaWiki, but not the other way around. Giving MediaWiki DT dependencies would be a terrible, terrible idea.

It’s not DT and MediaWiki core, it’s DT and MobileFrontend. (What’s from core – the non-JS edit form – does already handle preloads.) It’s a common and perfectly acceptable practice that extensions depend on each other (it may even be an “optional dependency”, i.e. that MF uses the functionality provided by DT if it’s available, and provides a fallback if it isn’t, e.g. it redirects to the non-JS form). Core having hard dependencies on extensions is a bad idea, I know, but no one wanted here to do that.

Sorry for the confusion. Still, in general I'd say this should be avoided when reasonably possible. If there is lots of overlap between extensions and one really benefits from the other being around it can make sense, but that's not really the case here and it would just result in another bit of depency hell. I'm also thinking about non-WMF wikis, which sometimes (e.g. PCGW) don't even use wiki for discussions, but that doesn't mean they'd have no use for MobileFrontend or the ability to preload content. To a degree, I'd also argue that preloads are often intended to be used in source mode anyway, so in the event of a specified preload switching to source mode wouldn't be all that unacceptable in my eyes, though it'll be neater if it works with visual too.

Recently, one of our community also reported a problem using preloaded text from an inputbox in Wiktionary in Incubator to create new dictionary lemmas. Any update on this 7 year old bug?

Change 904662 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/MobileFrontend@master] Editors use preload and preloadparams if present

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

So, that patch works. I put it up while I was falling asleep, so I might need to go back over it and verify things. That said, it's done in the most basic way possible and I'm debating whether it should migrate more of the parameters into the mobile routing fragment to be consistent.

Change 904662 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Editors use preload and preloadparams if present

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

Change 921478 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/MobileFrontend@master] editor: Use core prop=info&inprop=preloadcontent API instead of VE API

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

Change 921478 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] editor: Use core prop=info&inprop=preloadcontent API instead of VE API

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