Page MenuHomePhabricator

Unable to Expand Headings when Previewing New Page Created on Mobile
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue:

  • On Wiktionary mobile website go to an uncreated page, say 柔魂
  • If the page creation window does not appear automatically (or if one closes it), click the edit button at the top or the "create this entry" text. Switch to "Source editing" mode if not already selected.
  • Try to create the page, e.g. with the text "{{subst:zh-n|n|[[ghost]]}}". Whether you use a template or create the headings/text manually makes no difference.
  • Hit the blue "next" arrow to go to the page preview.

What happens?:
There will be a heading ("Chinese" in this case), but you will be unable to expand the heading, so you cannot see any of the page content beyond that.

This is similar behavior to that reported at T336572 (which is marked as resolved), except that I am unable to expand the heading, which is pretty detrimental. See the screenshot there, it looks the same.

What should have happened instead?:

You should be able to at least expand the heading, although ideally the heading should already be expanded.

Note that this intended behavior already exists, but in order to get it to work you have to close the page creation window (which pops up automatically), open the hamburger menu, then click "Edit full page". Magically, now when you create the page and preview it, the heading is automatically expanded for you and you can see the full page! It's unclear to me why this workaround functions, since ostensibly both buttons lead you to the same page (https://en.m.wiktionary.org/w/index.php?title=柔魂#/editor/all) so there must be something going on behind the scenes, which seems odd to me since you would think that creating a brand new page and editing the full empty/new page would do the same thing.

Other information
Same behavior on both Firefox and Chrome (Android). I have had this issue for quite a long time now; there was a period when closing and reopening the editor (or refreshing the page) would fix it, but it no longer does and instead it seems I now have to click "Edit full page".

Event Timeline

I went through the reproduction steps and spotted the Edittools gadget erroring out, but I've fixed the checks for missing elements and that error has been cleared up. That gadget is installed by default for all logged-in users, so it could have been erroring out and causing some other JavaScript to not run. (I also had to fix one of my scripts, but that isn't relevant to most users.) Now the Edittools error doesn't appear in the JavaScript console, but it's still impossible to expand the heading, so the cause is something else.

@Erutuon Indeed it's not yet working; do you happen to know the difference between hitting the "edit" button on a new page versus hitting the "edit full page" button? One would think their behavior should be identical so I would imagine there might be some difference causing the issue.

Jdlrobson subscribed.

This seems to impact all sites. Thanks for reporting!

I can also replicate on https://en.m.wikipedia.org/w/index.php?title=SAassaas#/editor/all

Screenshot 2024-01-30 at 6.05.29 PM.png (314×1 px, 13 KB)

I think the collapsible-block-js class is missing and the mfTempOpenSection(1) onclick shouldn't be there.

I can reproduce on enwiktionary, itwiki, frwiki, and locally; also on enwiki, but NOT at the link given in T356145#9500766, so maybe caching plays a role?

I can reproduce on enwiktionary, itwiki, frwiki, and locally; also on enwiki, but NOT at the link given in T356145#9500766, so maybe caching plays a role?

Nevermind, I can reproduce at that link too, but not when I follow it directly. Instead, I have to enter the page name manually into the URL, and click "edit" to open the editor.

It seems to be keyed to having followed an ?action=edit link. If I directly navigate to a #/editor/all link then it doesn't happen.

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

[mediawiki/extensions/MobileFrontend@master] Only hide Toggler if it's within collapsible-headings-collapsed

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

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

[mediawiki/extensions/MobileFrontend@master] Toggler can also hook wikipage.content on action=edit (for previews)

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

Issue is a combination of two things:

  1. Toggler only registers a wikipage.content hook on action=view, and that hook is required for it to work with headings in previews. This has been true since at least 2019.
  2. Toggler fails-hidden if content that expects it to run is present and it hasn't loaded. Thus when it didn't load, you couldn't even see the section contents.

The action=view issue is only present if you directly visit an action=edit URL, which will happen if you're either following a desktop link or creating a new page -- if you're on an existing page we load the editor dynamically on top of the view unless you manually navigate away. Wikitext editing on mobile is a pain, so I'd imagine that relatively few people were actually adding headings in wikitext right when they were creating a new page.

Patches address these two issues separately.

Appreciate the brisk responses, I really should've brought this up sooner!

Wikitext editing on mobile is a pain

And as someone who primarily edits on mobile with wikitext, I really have to agree, but this will certainly help!

Change 994390 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Toggler can also hook wikipage.content on action=edit (for previews)

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

Change 997961 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] Avoid repaints on collapsed sections

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

The issue described in this ticket seems fixed. Can the ticket be close @DLynch ?

@TheDJ Nominally the process is that the PM for the editing team is supposed to look over the stuff in that "ready for sign off" column and do the actual closing. This one might have fallen through the cracks, though...