Page MenuHomePhabricator

Live preview returns IP address as signature
Closed, ResolvedPublicBUG REPORT

Description

What is the problem?

If using API Parse anonymously[1] on a wiki with IP Masking enabled, signatures (~~~~) are rendered as the user's current IP address.

reply_tools_signature.png (419×978 px, 15 KB)

(Example from Reply tools on https://de.wikipedia.beta.wmflabs.org)

This is not an accurate representation of how the page will actually look when it is saved. When the edit is saved a new temporary user will be generated and the signature will be that of the new temporary user.

When using the default preview in Wikitext editor (the "Show preview" button), signatures are rendered as temporary account names. I don't know how it does this.

default_preview_signature.png (235×564 px, 19 KB)

(Example from default preview on https://de.wikipedia.beta.wmflabs.org)

The list of things this affects includes Reply tools, Real-Time Preview and Live Preview.

Steps to reproduce problem
  1. Go to https://de.wikipedia.beta.wmflabs.org/wiki/Benutzer_Diskussion:*Unregistered_3497
  2. Make sure you are not logged in nor have a temporary account (which will be displayed in the top right. You may need to clear your cookies.)
  3. Click the button Eine Diskussion beginnen
  4. In the textarea, type ~~~~

Expected behavior: It is replaced by a string of the form *Unregistered 1234 11:43, 7. Mär. 2023 (CET)
Observed behavior: It is replaced by <ip address> 11:43, 7. Mär. 2023 (CET)

Alternatively, if you have curl you could run this in the command line:

curl 'https://de.wikipedia.beta.wmflabs.org/w/api.php' -X POST -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' --data-raw 'action=parse&format=json&formatversion=2&text=%3Cspan%3E~~~~%3C%2Fspan%3E&contentmodel=wikitext&prop=text&onlypst=true'

and you will get something like this back:

{"parse":{"text":"<span>[[Spezial:Beiträge/<ip address>|<ip address>]] 11:47, 7. Mär. 2023 (CET)</span>"}}

This should be:

{"parse":{"text":"<span>[[Spezial:Beiträge/*Unregistered 1234|*Unregistered 1234]] 11:47, 7. Mär. 2023 (CET)</span>"}}
Environment

Wiki(s): https://de.wikipedia.beta.wmflabs.org MediaWiki 1.40.0-alpha (f139afe) 08:20, 7 March 2023.

Notes
  1. "Anonymously" meaning you are neither logged in as a named user nor have a temporary account. You may need to clear your cookies before testing.

Event Timeline

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.

tstarling renamed this task from API Parse returns IP address as signature to Live preview returns IP address as signature.May 4 2023, 12:55 AM
tstarling added a subscriber: matmarex.

@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

Ryasmeen added a subscriber: Ryasmeen.

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.

Screenshot 2023-10-02 at 9.20.05 PM.png (1×2 px, 530 KB)

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

Screenshot 2023-10-02 at 9.39.58 PM.png (1×2 px, 491 KB)

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.

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

image.png (2×3 px, 574 KB)

Once you submit the edit form, the temporary username should appear.

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