[go: up one dir, main page]

Page MenuHomePhabricator

The mobile editor doesn't prefill with content like the desktop editor
Closed, ResolvedPublic

Assigned To
Authored By
DonTrung
Jan 15 2019, 4:01 PM
Referenced Files
F28006246: prefilled.gif
Jan 23 2019, 6:06 PM
F28003711: wp_ss_20190123_0002.png
Jan 23 2019, 11:58 AM
F28003709: wp_ss_20190123_0003.png
Jan 23 2019, 11:58 AM
F28003715: wp_ss_20190123_0001.png
Jan 23 2019, 11:58 AM
F27899973: wp_ss_20190115_0006.png
Jan 15 2019, 4:01 PM
F27899979: wp_ss_20190115_0007.png
Jan 15 2019, 4:01 PM
Tokens
"Baby Tequila" token, awarded by Ciencia_Al_Poder."Cup of Joe" token, awarded by MusikAnimal.

Description

  • Certain URIs prefill the wikitext editor with content e.g. this desktop url by a "create" query string parameter.
  • When visiting the same url on mobile although the non-JS error is prefilled with the correct content, this is not inherited by the mobile JavaScript based editor (wikitext OR VisualEditor).

prefilled.gif (499×495 px, 495 KB)

original report

Whenever I try to edit a page with the mobile editor that already has mark-up it goes from this:

wp_ss_20190115_0006.png (2×1 px, 238 KB)

To this:

wp_ss_20190115_0007.png (2×1 px, 121 KB)

Is there a way to prevent the mobile editing interface from switching from the former to the latter?

Event Timeline

Aklapper changed the task status from Open to Stalled.Jan 15 2019, 4:15 PM

Hi @DonTrung, thanks for taking the time to report this!
Unfortunately this report lacks some information. If you have time and can still reproduce the problem: Please add a more complete description to this report by providing a specific link to an example where the issue can be seen and information about your web browser(s) and operating system.
You can edit the task description by clicking Edit Task.
Ideally, exact and clear steps to reproduce should allow any other person to follow these steps (without having to interpret those steps) and see the same results. Problems that others can reliably reproduce can get fixed faster. Thanks!

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.

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

@DonTrung: Unfortunately closing this report as no further information has been provided.
After you have provided the information asked for and if this still happens, please set the status of this report back to "Open" via the Add Action...Change Status dropdown. Thanks!

@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.

wp_ss_20190123_0001.png (2×1 px, 398 KB)

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

wp_ss_20190123_0002.png (2×1 px, 240 KB)

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

wp_ss_20190123_0003.png (2×1 px, 121 KB)

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.

Aklapper added a project: MobileFrontend.

Thanks! Looking at https://www.mediawiki.org/wiki/Editor I think this is "MobileFrontend's current wikitext editor" hence adding MobileFrontend here.

Jdlrobson renamed this task from The mobile editor removes mark-up to The mobile editor doesn't prefill with content like the desktop editor.Jan 23 2019, 5:49 PM
Jdlrobson added a project: VisualEditor.
Jdlrobson updated the task description. (Show Details)

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.

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).

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.

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.

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.

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.

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