Change 881485 had a related patch set uploaded (by Tacsipacsi; author: Tacsipacsi):

[mediawiki/core@master] Return redirect flag in parse API, use in live preview

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

Change 881485 abandoned by Tacsipacsi:

[mediawiki/core@master] Return redirect flag in parse API, use in live preview

Reason:

In favor of I61c4080bc432a0dae03083a027890e7de786898c

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

Yes, no worries. Thanks!

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

[mediawiki/core@master] Dynamically update template list for live preview

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

Change 844318 merged by jenkins-bot:

[mediawiki/core@master] Dynamically update template list for live preview

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

@Samwilson Before I proceed to do a few more testing, is this what you are talking about with the italics on the redirects that should be continued?

Test link: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=T327354:Real-time_preview_(and_live_preview)_don%E2%80%99t_highlight_redirects_in_italic;_Bug_Report&action=edit
OS: macOS 13.0
Browser: Chrome 109

Patch	Non-RTP	RTP
After Patch

Patch	Non-RTP	RTP
Before Patch

is this what you are talking about with the italics on the redirects that should be continued?

Yep, that's the right place.

@Samwilson I am getting errors when I have a lot of templates on a page. I think due to the length of the URL/number of titles when making the API request to look up page protections.

For example:

• https://en.wikipedia.beta.wmflabs.org/wiki/TemplateUsageArticle678 with ~650 templates returns a net::ERR_HTTP2_PROTOCOL_ERROR (on Chromium at least)
• https://en.wikipedia.beta.wmflabs.org/wiki/I_am_on_the_%22Selenium_mobile_watched_page_test_1562018575699 with 87 templates returns 414 Request-URI Too Long (on beta, not sure if production would accept a longer URL)
• https://en.wikipedia.beta.wmflabs.org/wiki/TemplateUsageArticle121 with 45 templates returns Object { code: "toomanyvalues", info: "Too many values supplied for parameter \"titles\". The limit is 50.", limit: 50, … } (does not happen when you are logged in, I guess because the API accepts more titles for logged in users?)

@Samwilson Here are a few more issues that I came across so far

Testing on:
OS: macOS 13.0, Windows 11
Browsers: Chrome 109, Safari 16.0, FireFox 109, Edge 109
Testing: Show preview without reloading the page; Restriction Levels
Environment: Beta
Testing link: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=T327354:Real-time_preview_(and_live_preview)_don%E2%80%99t_highlight_redirects_in_italic;_Bug_Report&action=edit

Issues

Section Header Edit - When you click on the section header as seen in the screenshot in the Notes section, Template used dropdown does not show up when there is No Preview but it does in RTP.

Issue	No Preview	RTP	Notes
Section Header Edit

Template Dropdown - Template used dropdown wording is different between No Preview and RTP as seen highlighted below.

Issue	No Preview	RTP
Template Dropdown

Good

Test	No Preview	W/Preview	Disable JS
Template String

In T327354#8626589, @GMikesell-WMF wrote:

Section Header Edit - When you click on the section header as seen in the screenshot in the Notes section, Template used dropdown does not show up when there is No Preview but it does in RTP.

This has always been this way, regardless of whether RTP (or live preview) is enabled or not – the templates used in the section appear only once a preview is done (which happens automatically when RTP is enabled). Maybe it’s due to performance issues? When the whole page is edited, the used templates can be got from the templatelinks database table, but it doesn’t have per-section granularity, so probably a parse would be necessary, which may be abused for denial-of-service attacks (the initial loading of the editor is a GET request, which likely doesn’t have as strict rate limits as the previews, which are POST requests).

Template Dropdown - Template used dropdown wording is different between No Preview and RTP as seen highlighted below.

Of course – when there’s no preview, the software can’t show the templates used in the preview. When there’s a preview, it can and does.

Thanks @dom_walden and @GMikesell-WMF those are all great points.

• The too-many-templates problem is for the protection info and not for the actual list of templates, luckily (the latter is returned as part of the parse result, and is happy to return more than 50 for anon users). We can avoid the 414 Request-URI Too Long by switching to POST the request for protection info. That won't help with the limit of 50, so for that I think we should add a loop to continue fetching the remaining info when there is more. However, I think this is also more related to T321032 than to this task so I'll carry on with it over there.
• I think the lack of the template list without previewing is fine and is long-standing, as @Tacsipacsi points out. It sort of feels like it'd be nice to have it already there on load, without a preview, but now RTP will do that immediately anyway I don't think it's worth doing anything to make it happen server-side, especially if could impact performance.
• Regarding the different wording of "Templates used on this page" vs "Templates used in this preview": there's also "Templates used in this section" which shows when previewing a section. I'm not sure if anything needs to change with these, but it does seem slightly odd that there's no section-preview equivalent, e.g. "Templates used in this section preview". We could either add that, or remove the other — I slightly lean towards the latter, because "Templates used in this page" and "Templates used in this section" are both valid labels during previews.
• I think the big error that I introduced above is the missing i18n message for the restriction level. This will be fixed as a follow-up to T321032.

tldr: nothing left to do here unless we want to fix up the list header message situation. @NRodriguez what do you think?