Which, granted, is pretty customized. The error I get is "The "reply" link cannot be used to reply to this comment. To reply, please use the full page editor by clicking "Edit source"." Now, interestingly, the user script at https://en.wikipedia.org/wiki/User:Enterprisey/reply-link still works (most of the time) on my page, so it seems more robust that your tool here. Might be worth checking why that is.
Oh yeah, my talk page is here https://en.wikipedia.org/wiki/User_talk:Piotrus
Weirdly, when I copy your /talkheader page directly into a test page, it works fine. I'm not sure what the problem is. Feel free to poke around in my sandbox's talk page if you want to try to debug it.
Could be a problem with some particular post. I copied everything else and replicated the problem https://en.wikipedia.org/wiki/User_talk:Whatamidoing_(WMF)/sandbox
Now I guess we need to delete posts one by one and see when this error stops triggering. This could help identify the broken code.
I tried a couple of things, and didn't find the pattern. The header by itself works, the commments by themselves work, but together, it doesn't. It might be a "combination" rather than a simple thing. Please do post here if you figure it out.
I did a bunch of 'remove x' and see what happens. What I ended up with was removing the transclusion (see here and here) and it fixed the problem. The weird thing is that no code was removed except the transclusion itself. I don't think it was the struck out old code, as removing it from the transcluded page didn't help. But it the transculsion to {{User:Piotrus/Top}} which is still present does work. Any ideas what's going on?
No. Honestly, I think this is beyond our level, and we'd have to ask someone on the Parsing team. Well – maybe @Izno could figure it out? He's got a lot of experience with sorting out Special:LintErrors and this is probably related.
Looks like this is sorted now, I see Piotrus has recently made an edit with Reply.
@Izno Yes, but that required me to remove transclusion of subpage. Not sure if this actually matters (as in - does it include load time for my talk page), but we are still puzzled why it didn't work in the first place. It should, the fact that it did not means there is some bug somewhere, related to transcluding subpages/parsin. We did what we could - identified what causes the error. Now, the code needs to be fixed to prevent others form having to deal with the same problem, no?
Piotrus, so, the general-est rule with how our parsers work is that all content be well-formed i.e. all the HTML and wikitables have matching closing wikitext/HTML. If you don't close things, you get bad behavior. On talk pages, there is a known pattern where someone who wants a full page border/background will leave an element open with the appropriate stylings, like a wikitable or a <div>. This is often put into a transcluded header as you did. The case where something is unclosed but is transcluded cannot be handled by the Reply system generally; it knows there is something wrong with the page it is on but not what because the what is hidden by the transclusion. However, there is a specific workaround where the system allows the user to put that unclosed element directly into the talk page's wikitext, wherein the system will say "hey, this is unclosed, let me just ignore it". In this revision, you made it obvious to the system what that element was: You have a wikitable starting with {| width="100%". Accordingly, Reply started working.
@Izno I see, but why is the system able deal with this error when it is on that page, but not when it is on a subpage? Shouldn't the error on a subpage be either invisible, or if it is visible, treated the same way? It's like the system is getting information from the subpage that there is the error, but not what it is, and refuses to work without further information, treating the error as critical by default?
Note that that's how I understand it. I don't think you'll get any work on it. There are a couple devs who can probably explain why if you really want to know.
@Izno Low priority? I'd have thought it would be a more common problem but if it's not, that's ok. But could you file in a properly formatted bug report? I don't know how to do so, but it does seem like something that in theory, one day, should be fixed, no?
Low priority, high effort, clear and trivial work around, and providing the workaround has already been actively worked as part of this project. (It's documented at Help:DiscussionTools.)
I'm not going to file a report for this one, sorry. @Matma Rex may be interested in filing one or knowing if there is one to hand, or even if it would be technically feasible to resolve at all. (Developers should provide a link from their personal account to their developer account. ;)
> (Developers should provide a link from their personal account to their developer account. ;)
Or maybe not, if the personal account is more likely to reach the dev. ;-)
Feel free to file a bug, I couldn't find an existing one (although I feel like I've discussed the same problem on Phabricator somewhere…).
It's definitely a real issue, and in theory, one day, it should be fixed. But making it work would require changes in Parsoid, basically the same thing that would be required to have visual editing of template parameters in VisualEditor (currently, everything in the template dialog is edited as wikitext), which have a task for them: T71870 but it hasn't been touched since 2015.
@Matma Rex "Feel free to file a bug". Could you be so kind and to file it? As I said, I don't know how.
