There's an error in the browser console:
Uncaught URIError: URI malformed at decodeURIComponent (<anonymous>) at Function.Uri.decode (<anonymous>:180:39) at <anonymous>:180:494 at String.replace (<anonymous>) at Uri.parse (<anonymous>:180:350) at new Uri (<anonymous>:179:86) at getPageTitleFromUri (load.php?lang=hu&modules=ext.discussionTools.parser|jquery&skin=vector&version=16kac:6) at load.php?lang=hu&modules=ext.discussionTools.parser|jquery&skin=vector&version=16kac:7 at Array.some (<anonymous>) at findSignature (load.php?lang=hu&modules=ext.discussionTools.parser|jquery&skin=vector&version=16kac:7)
Fri, Feb 21
@Jdlrobson I think that should happen in the opposite order. I assure you I'll merge both patches when they are working, I think this is a good idea. But I will not merge additional code into core if there's no guarantee that it is ever going to get used.
Well the formatting is super messed up, there's a newline in the middle of the timestamp (where a ':' should be).
I tried reproducing on https://translate.google.com/, but it insists on redirecting me to the mobile view, where DT is not available yet.
We're failing to detect these signatures because the timezone indicator – '(تعم)' and '(ت ع م)' in these examples – is different from the current version: https://ar.wikipedia.org/wiki/ميدياويكي:Timezone-utc. (This is a translation of "UTC", currently it has the letter separated by non-breaking spaces, previous versions had normal spaces or no separators.) If you look at the history of that page, it last changed in 2013 and several times before that.
There is an invisible Unicode character U+200E (https://en.wikipedia.org/wiki/Left-to-right_mark) after the "16:32", which is causing the timestamp parser not to match it.
Personally I'd say that this task is really just about whether the tool is available, which it clearly is, since you've been doing thorough testing for T244432.
Yes and yes.
This is the same situation as T245695, but with <i> elements (italics text formatting) instead of images.
Thu, Feb 20
Yes… I think that's not what was supposed to happen. *sigh*
This seems to work correctly for me now? The patch for T178976 might have fixed it.
Sorry, I forgot to move this.
This happens for the same reason as T245574, I'll merge them.
The blue box appears because of custom styling for discussions on fr.wp. But the underlying issue is in our code, we don't properly clean up cancelled replies. You can also see similar issues when replying to a comment in a bullet list on any wiki (after closing the reply box, some extraneous bullet points will remain visible).
The issue is probably in WikitextSerializer::formatStringSubst().
Huh, I didn't know about Special:SuggestedTags, looks cool…
This task sounds big and scary but we've been thinking about this from the start, when deciding how posting replies should work, so it should be easier than it looks like.
This happens because we try to recognize comments with a timestamp but without a signature. This was meant to allow replying to announcements posted by some bots, e.g. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_179#Tech_News:_2020-06 (note how the initial comment ends with "20:04, 3 February 2020 (UTC)" and no signature). But it seems like it will cause issues more often than it helps, so we should probably only detect comments with real signatures.
Wed, Feb 19
No, we discovered during review that the proposed patch would regress T73718. It needs some more experimentation to find a solution that doesn't cause that.
Tue, Feb 18
I filed a bug in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1053757
It works for me on https://ar.wikipedia.org/wiki/نقاش:الصفحة_الرئيسية (this is the talk of the mainpage). Can you give a link to the broken page?
T213253 might also be a duplicate.
For completeness: on Firefox and IE, middle-clicking the text of the page doesn't place the text cursor, and so this issue doesn't occur on those browsers. So this is a Chrome bug, I'm not sure if we can work around it.
I can reproduce this. Note that you have to press, hold, and let go of the button really fast and while moving the mouse to trigger the problem. I initially couldn't reproduce it because of that (and also, I didn't even know you and press and hold the middle mouse button, I always click it once to enter the scrolling mode, then click again to exit it).
It should be fixed now, the "Reply" links no longer appear without the query parameter.
Sorry about that… we're debugging the problem right now.
Mon, Feb 17
(Feel free to submit a patch, otherwise I'll write one in a few days)
I can reproduce, this is a VE bug.
@Akinwale-microsoft I assume all of the patches you've been submitting are based on this report? Thank you for working on this!