Talk:Talk pages project/Replying

Issues

I don't know if it's better to report this directly only on phabricator or here or whether this is already tracked (if so this could be archived):

• When somebody screwed up intendation, ie with the source editor added a reply without intendation (same layer as original post), then it puts the reply above that comment that misses intendation when using the Reply tool instead of putting it at the bottom. I hope it's clear what I mean. It should put the reply in the correct layer at the bottom and maybe it could even fix the intendation of other comments.
• The reply button is missing in empty sections. I'm not entirely sure what I meant with that or which problem I had where the button was missing but I think e.g. here there should also be a reply button in those sections that only have a header so one can use the Reply tool for replying instead of the source editor.
• It would probably be great if you could add a button to mark a section as solved to the options (see c:Template:Section resolved).
• People often if not usually use a bullet point in deletion discussions. With the reply tool it moves the signature to a new line. Please enable that the signature can also be put into the same line somehow. Example solution: if a comment only has one bullet point but not multiple it should not add a newline at the end.

Prototyperspective (talk) 22:23, 24 September 2024 (UTC)

Also included the request for a mark as solved button in meta:Community Wishlist/Wishes/Do not fully archive unsolved issues on Talk pages. There's further issues (I'll add some below). If there's no phab issues for these I intend to submit code issues there later since I hope this could be moved from beta to become the default way people reply on talk pages with few exceptions.

• When using <gallery> it shows correctly in the preview but screws it up when publishing due to the intendation. See e.g. c:Special:Diff/949550947.

Prototyperspective (talk) 17:32, 26 October 2024 (UTC)

• When using templates it can add double dots : example (here is the change to how the reply should have looked like).

Prototyperspective (talk) 01:53, 6 March 2025 (UTC)

Community Wishlist request with more: Wish:Fix the issues breaking the Reply tool. Prototyperspective (talk) 12:05, 15 May 2025 (UTC)

Inappropriate activation

I happened to look at the page history of a page on which I had an open pending reply. I was just looking at some diffs, but these also display a copy of the page as it was. This caused the "resurrect saved but unsent reply" feature to open a comment dialog box in the old versions and IIRC scroll to it. At some point, I think I submitted the comment but still had other tabs open. But because they were looking at older versions, it looked like the comment hadn't been submitted, and I nearly submitted it twice. This feature should not activate when looking at non-current versions. -- Beland (talk) 12:26, 2 May 2025 (UTC)

Quick reply temperamental

I don't know if this is the right place to raise this, but recently (last few weeks?) the reply tool sometimes works, sometimes doesn't (as in, I click on 'Reply' and nothing happens). Sometimes reloading the page resolves this, although not necessarily on the first attempt; sometimes I have to relaunch the browser. Any idea what might be causing this? (The browser I'm using is Vivaldi 7.4, on macOS 12.7.6.) DoubleGrazing (talk) 10:59, 22 June 2025 (UTC)

Problem with shift key

Often when I press the shift key to capitalise a letter on Wikipedia the cursor moves back to the start of the message I am typing.

I am running macOS Sequoia 15.5 and I alternate between Firefox (can't tell you which version because the browser updates frequently) and Safari 18.5. Qwerty123M (talk) 06:32, 18 July 2025 (UTC)

This is a problem caused by the "GoogleTrans" gadget. It resets the cursor/selection whenever you press Shift.

See past bug reports:

• T156228: Pressing the Shift key moves the cursor (when "GoogleTrans" gadget is enabled)
• en:User talk:Endo999/GoogleTrans#After enabled the widget, cursor would relocate unexpected after pressing "Shift" key when typing mid-line in New Discussion Tool replying to comment in Source Code mode

Matma Rex (talk) 21:13, 18 July 2025 (UTC)

Source mode preview lag

The lag on source mode typing is connected to preview render in such a way that any lag in the preview render is a lag in typing. It essentially seems to block entry until the preview finishes rendering. There also doesn't seem to be a way to disable the preview below the entry box (apologies if I missed it) so I can't solve it that way. It at times makes the source mode editing essentially unusable. I think it seems to be happening on larger pages, but not sure. I'm noticing it when editing on wikipedia.Driftingdrifting (talk) 18:22, 21 August 2025 (UTC)

Hi, thanks for the report! I can't reproduce this problem, though: I don't see any lag when I type, even though the preview only updates once a second or so. I made a quick screen recording for reference: https://phabricator.wikimedia.org/F65825451

(I tried on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical) too, since it is a much larger page, and it behaves the same there)

There is indeed no way to disable the preview, but note that the visual mode doesn't have (or need) a preview box, so perhaps that is an option for you. Matma Rex (talk) 23:35, 21 August 2025 (UTC)

The page I can most reliably reproduce on is https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents. I suppose its possible its a weird interaction with one of the other beta features? I can sometimes induce here by slowing CPU/network, having a large message in the text box here, and then typing quickly.

The normal behavior I see (that I would expect) is just that the preview takes a little bit of time to come in, but doesn't block text entry in the source field, but when its bugged it seems to essentially be redrawing the preview on each character and waiting for text to show up before displaying the typed character. It really does seem like there is some dependency at some level between the preview redraw and the characters appearing in the text box. Driftingdrifting (talk) 23:47, 21 August 2025 (UTC)

I couldn’t reproduce this either, even though I also experience CPU spikes quite often.

As a workaround, you could try disabling editing tools in source mode in your preferences. The source editor with editing tools relies on JavaScript more than the one without editing tools, and I’d expect native HTML things to be more resistant to CPU spikes. —Tacsipacsi (talk) 15:17, 24 August 2025 (UTC)