Change 909380 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] api: Use a temp placeholder for signature on preview/pst

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

Per my comments on the Gerrit patch: I disagree with the task description. The main problem is that live preview shows an IP address. ApiParse is just an implementation detail.

My idea for fixing it is:

• Deliver the temporary username acquisition status to JS, say as a config variable.
• When preview is requested, if temporary username acquisition is permitted but not yet done, post an API request to acquire the username. This can be a new API action.
• The ApiParse request will proceed after the username is acquired.
• In ApiParse, use the stashed username from the session if it is available.

After that is done, there is the remaining problem that when ApiParse is asked for a PST of a signature when name acquisition has not been done, an IP address will be shown. That seems like a minor issue -- it should ideally not be user visible. But my idea for fixing it is:

• If temporary username acquisition is permitted but not yet done, have ApiParse use a placeholder (TempUserCreator::getPlaceholderName())
• In Parser::getUserSig() we have:

		if ( $this->userNameUtils->isTemp( $username ) ) {
			$msgName = 'signature-temp';
		} elseif ( $user->isRegistered() ) {
			$msgName = 'signature';
		} else {
			$msgName = 'signature-anon';
		}

A fourth case should be added, using a new message signature-placeholder when the username is a temp user placeholder. This would give some localised placeholder signature.

@matmarex: do you have any thoughts on this? I see you have been working on the equivalent issue in VisualEditor (T332435).

I haven't started implementing it yet, but I was going to make VisualEditor acquire a username when previewing, and I was planning the same for DiscussionTools's reply and new topic tool (mentioned in this task). I think that reaching the point in the editing process where you preview the edit is a fairly strong signal that you're planning to save it (although I don't have the numbers for this; maybe it'd be interesting to find out).

The only exception where I wouldn't acquire a username, and display a placeholder, is when we display a preview on the initial page load – e.g. when using &preview=yes in EditPage (hence I +2'd https://gerrit.wikimedia.org/r/c/mediawiki/core/+/909390), or the new topic tool with preloaded text in DiscussionTools.

Your proposed API seems reasonable. I suppose it could also be a parameter on action=parse to trigger this, which would be more convenient to use and would save a roundtrip, but I can see the reasons to keep these things separate. And we can use async and await in the JS code since a few days ago, so the inconvenience is minimal.

I also like the idea for improving the placeholder.

Change 909380 merged by jenkins-bot:

[mediawiki/core@master] api: Use a temp placeholder for signature on preview/pst

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

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

[mediawiki/core@master] Acquire a temporary user username before previewing

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

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

[mediawiki/extensions/VisualEditor@master] Acquire a temporary user username before previewing

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

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

[mediawiki/extensions/DiscussionTools@master] Acquire a temporary user username before previewing

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

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

[mediawiki/extensions/MobileFrontend@master] Acquire a temporary user username before previewing

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

Change 938957 merged by jenkins-bot:

[mediawiki/core@master] Acquire a temporary user username before previewing

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

Change 938960 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Acquire a temporary user username before previewing

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

Change 938959 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Acquire a temporary user username before previewing

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

Change 938958 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Acquire a temporary user username before previewing

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

(QA is covered in T344468)

Live preview is now showing a temporary username instead of IP address in both Discussion Tools and for Wikitext editor.

However I don't see the exception @matmarex mentioned here being implemented.

1. When &preview=yes is appended while editing a page anonymously in wikitext editor, if I click on preview I do see a temporary username for signatures.

2. When new topic tool opens with preloaded text in DiscussionTools, it shows a temporary username acquired for signatures.

In T331397#8825577, @matmarex wrote:

I haven't started implementing it yet, but I was going to make VisualEditor acquire a username when previewing, and I was planning the same for DiscussionTools's reply and new topic tool (mentioned in this task). I think that reaching the point in the editing process where you preview the edit is a fairly strong signal that you're planning to save it (although I don't have the numbers for this; maybe it'd be interesting to find out).

The only exception where I wouldn't acquire a username, and display a placeholder, is when we display a preview on the initial page load – e.g. when using &preview=yes in EditPage (hence I +2'd https://gerrit.wikimedia.org/r/c/mediawiki/core/+/909390), or the new topic tool with preloaded text in DiscussionTools.

Your proposed API seems reasonable. I suppose it could also be a parameter on action=parse to trigger this, which would be more convenient to use and would save a roundtrip, but I can see the reasons to keep these things separate. And we can use async and await in the JS code since a few days ago, so the inconvenience is minimal.

I also like the idea for improving the placeholder.

In T331397#9218532, @Ryasmeen wrote:

However I don't see the exception @matmarex mentioned here being implemented.

1. When &preview=yes is appended while editing a page anonymously in wikitext editor, if I click on preview I do see a temporary username for signatures.

This is expected after clicking "Preview". The username is only missing on the initial page view (when you view a page with &preview=yes and preloaded content that includes your signature – for example: https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Diskussion:Test&action=edit&section=new&preloadtitle=~~~~&preview=yes).

2. When new topic tool opens with preloaded text in DiscussionTools, it shows a temporary username acquired for signatures.

Yes, I didn't get around to implementing this in the end. It would be a bit more complex to do this in DiscussionTools (our code for autosave and preload is a bit messy and it's difficult to distinguish where the content came from when generating the preview), and I thought it wasn't worth the complexity for a feature that almost no one uses.