Page MenuHomePhabricator

Inconsistency when using Realtime Preview for Category pages
Closed, ResolvedPublic3 Estimated Story PointsBUG REPORT

Description

What is the problem?

When you edit a page in the Category namespace, the Realtime Preview does not show the pages or subcategories in the category. See first screenshot.

However, after you click "Show preview" (to show the normal preview), the Realtime Preview does show the pages and subcategories.

I guess we want them both to be consistent.

Steps to reproduce problem
  1. Login to https://commons.wikimedia.org and enable Realtime Preview
  2. Go to https://commons.wikimedia.org/w/index.php?title=Category:Volvo_PV544&action=edit
  3. Open Realtime Preview
  4. Observe in the RTP pane that there is just the infobox
  5. Click "Show preview"
  6. Observe in the RTP pane there is also Subcategories, Pages in category and Media in category
Environment

Wiki(s): https://commons.wikimedia.org MediaWiki 1.39.0-wmf.25 (cec9041) 16:16, 16 August 2022.
Editor: WikiEditor 0.5.3 (ae3b860) 06:27, 15 August 2022.

Screenshots

RTP without normal preview, without pages and subcategories (action=edit):

category_rtp_before.png (992Γ—1 px, 185 KB)

RTP with normal preview, showing pages and subcategories (action=submit):

category_rtp_after.png (954Γ—1 px, 327 KB)

Event Timeline

Important detail -- this only happens when Live Preview is turned off ("Show previews without reloading the page" in your preferences). When I first tested this I had Live Preview on, and noticed I wasn't seeing categories or subcategories in the larger preview pane either. That tells me this is an issue with Live Preview (which RTP leverages). It may be a regression from when we first started this project, though. T101809 suggests there was a time when Live Preview showed category members.

Samwilson subscribed.

I think this is because we're cloning the #wikiPreview element, and in the case of a category page it contains HTML other than that which is separately going to come from the parse API.

One possibly simplistic fix is to remove .mw-category-generated from the cloned element. We only actually want this HTML:

<div dir="ltr" class="mw-content-ltr" lang="en"><div class="mw-parser-output">…</div></div>

But in the case of a category page, we get this structure:

<div class="previewnote"></div>
<div dir="ltr" class="mw-content-ltr" lang="en"><div class="mw-parser-output">…</div></div>
<div class="mw-category-generated" dir="ltr" lang="en"></div>

The .previewnote element is removed by pagePreview.doPreview() but the mw-category-generated is not.

We're doing the clone because the innerHtml of #wikiPreview is constructed server-side (in EditPage.php) and we didn't want to repeat that. I have a bit of a memory that there was some issue with doing it client-side, but actually all we want is something like the following, which shouldn't be too difficult.

<div dir="ltr" class="mw-content-ltr" lang="en"></div>

I'm going to try to make that change now. I think it can be simple if we assume there's only ever two directions. :-)

There seems to still be an issue with a difference between nonlive and live preview in the order of the category listing and the page text, but that is separate and possibly a long-standing issue.

Change 831373 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/WikiEditor@master] [Realtime Preview] Only clone part of the #wikiPreview element

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

There seems to still be an issue with a difference between nonlive and live preview in the order of the category listing and the page text, but that is separate and possibly a long-standing issue.

Yes, I that might be what T101809: live preview displays category page content below subcategories and files is about.

What is the desired consistency here? It seems to me that we shouldn't show the category list for any type of preview. The content being previewed isn't the category list, and can't change anything about the category list (well… I guess it could be self-categorizing, but in that situation it's even worse because the previewed category list doesn't include the self-cat). I think all types of preview (nonlive, live, and realtime) should not show the category list. Does that sound correct?

It's a similar situation with File pages, where there is other content that ends up being shown on the page β€” but in that case we never show it on preview.

If we do stick with not showing category lists on preview, we should also remove them from non-live preview.

What is the desired consistency here? It seems to me that we shouldn't show the category list for any type of preview. The content being previewed isn't the category list, and can't change anything about the category list (well… I guess it could be self-categorizing, but in that situation it's even worse because the previewed category list doesn't include the self-cat). I think all types of preview (nonlive, live, and realtime) should not show the category list. Does that sound correct?

It's a similar situation with File pages, where there is other content that ends up being shown on the page β€” but in that case we never show it on preview.

I hadn't thought about it this way, but yes, I agree it makes sense in this context to not show category members. However, I personally would expect to see them on a full page (non-live) preview -- but I think that's just because I'm used to it? You're right that generally folks aren't deliberately trying to preview members of a category, rather just the content they added to the category page.

If we do remove category members from the non-live preview we should be sure to tag User-notice and make sure something is in Tech News. I say this just because it's been this way for so long (forever?) so there will probably some people caught off guard, even though it seemingly would have little hindrance on editor workflows.

It seems to me that we shouldn't show the category list for any type of preview.

Agree with this take.

If we do remove category members from the non-live preview we should be sure to tag User-notice and make sure something is in Tech News.

Just tagged the user-notice. I am unsure if it needs to go on tech news as I understand that list to be about new releases. This is removing arguably not-core functionality on a preference that people have to have turned on. But happy to be challenged on that if you still think it's necessary!

This is removing arguably not-core functionality on a preference that people have to have turned on.

The change needed here is to MediaWiki core, and it's the default behaviour (i.e. nonlive preview always shows the category list). Most people use non-live preview; it's those who have turned on live preview that won't get the category list.

Once it's gone from core, Realtime Preview will not have to be changed.

You're right @MusikAnimal this is a very old feature β€” but I don't feel like it'll be too controversial (famous last words of course!). Still, I think perhaps a separate task that is focused on that point is probably worthwhile, so it can be linked from wherever it gets announced.

It may be a regression from when we first started this project, though. T101809 suggests there was a time when Live Preview showed category members.

I've been trying to run MediaWiki 1.37 to see how live preview behaved then, before the changes we made. I'm not really sure how it would've been doing it, because it's always used action=parse hasn't it? Which never includes the category list. That task is seven years old, so perhaps there have been other changes in that time.

The patch above is ready for review, and I think is probably worthwhile even if after T318212 is resolved it'll not actually be necessary.

This all is based on the idea that we do want to get rid of category-lists in all previews (nonlive, live, and realtime).

Change 831373 merged by jenkins-bot:

[mediawiki/extensions/WikiEditor@master] [Realtime Preview] Only clone part of the #wikiPreview element

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

Hiyo. Re: Tech News - What wording would you suggest as the blurb-content (1-3 simple sentences), and When should it be included (Monday's edition, or later/TBD)? Thanks!

Sorry, I forgot that this was tagged for Tech News. I don't think we need to announce these changes, as actually we've not yet changed the main (nonlive) preview to not have the category list. There's now a separate task for that: T318212: Remove category list from preview of category pages

The changes here just bring realtime preview into line with live preview (i.e. without any category list). The bug was when someone did a nonlive preview of a category page followed by a realtime preview β€” so something of an edge case.

QA notes:

  • The category list should still show for nonlive preview.
  • It should not show in the RTP pane ever.
  • Note also the behaviour when creating a new category page (the category list shows when the page is loaded, regardless of previewing β€” or rather, the preview is forced when the page is loaded).

Subcategories, Pages in category and Media in category do not appear in the Realtime Preview pane. Only the part of the page's content that a user can actually edit is visible. See, for example, https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Category:Files_with_no_machine-readable_source&action=edit.

From my understanding, the change affects what gets added to the Realtime Preview pane when you first open it. Therefore, I tested opening RTP while normal preview was showing, while Live preview was showing and while no preview was showing. I checked that the content of the RTP pane was correct and that the HTML had the correct dir attribute (so that the content of an RTL page would appear in RTL in the Realtime Preview pane).

I did so for pages in a variety of namespaces (including editing an existing and creating a new Category). For normal preview, I tested on all 5 skins. For Live and no preview I tested Vector 2022 (mostly).

I briefly experimented with the two preferences "Show preview when starting to edit" and "Show preview before edit box", but they did not make any difference that I could see.

Test environment: https://en.wikipedia.beta.wmflabs.org WikiEditor 0.5.3 (c7e87e5) 08:21, 10 October 2022.
Test browser: Firefox 91