This doesn't seem like it needs access to the template frame stack (which is why we initially filed it under missing functionality) -- the {{ptag}} template is just:

<indicator name="phabricator-project">{{Badge|content=<translate><!--T:1--> [[<tvar name=1>Special:MyLanguage/Phabricator</tvar>|Issue tracker]]:</translate> [[phab:tag/{{lc:{{{1}}}}}/|'''#{{{1}}}''']]
}}</indicator>

And it seems that we're not fully recursing into that complex wikitext. We're parsing *some* of it, since the [[Issue tracker]] link is coming out, but the [[phab:tag/...]] business isn't.

That's probably just a plain-old parsing error of some sort.

While this feels related to T347507: Parsoid doesn't support extensions/modules which crawl the frame stack for arguments, I don't think that is the problem.

The issue is that the preprocessor should have processed the contents of indicator, but the preprocessor doesn't know to do that because it doesn't know that indicator content is wikitext.

@cscott yes .. we both landed on the same conclusion. :)

The thing is, this seems to work fine on enwiki, at least in my sandbox:
https://en.wikipedia.org/wiki/User:Cscott/T348722?useparsoid=1

The only thing I haven't copied here is the <translate> tags of the original, so I'm suspecting some interaction between annotations and the link parsing.

Odder still: in https://www.mediawiki.org/wiki/User:Cscott/T348722?useparsoid=1 the entire indicator disappears.

A small reproduction for this issue can be made by creating a template with the content

<span><indicator name="ptag">{{{1}}}</indicator></span>

(and then calling it with an arbitrary argument).

The problem is that, when we render an indicator, we parse the content of the extension as an independent document via $extApi->extTagToDOM, where the template frame and template arguments are not available anymore.

Hence, fixing T347507 might actually resolve this issue (and at least solve the issue of the availability of the frame arguments - which could then be passed somehow as a context to extTagToDOM).

Another solution/workaround would be to add a config option to tell the preprocessor to preprocess extension source recursively, so that it's already resolved when arriving in the extension.

In T348722#9246987, @ihurbain wrote:

A small reproduction for this issue can be made by creating a template with the content

<span><indicator name="ptag">{{{1}}}</indicator></span>

(and then calling it with an arbitrary argument).

We could also add support for <indicator ... contents="{{{1}}}"> which would also solve the problem? For that matter, {{#tag:indicator|{{{1}}}|name=ptag}} should also work. The issue is that extension tag contents are explicitly "not wikitext" and so (in a purely formal sense) we shouldn't "expect" argument expansion to work inside there.

This also affects a template on wikivoyage; @ihurbain knows the details.

In T348722#9246523, @cscott wrote:

The thing is, this seems to work fine on enwiki, at least in my sandbox:
https://en.wikipedia.org/wiki/User:Cscott/T348722?useparsoid=1

The reported issue does show up on en.wp at AIV:

There's probably a case to be made here that, as far as we can tell, these can be fixed on wikis by replacing <indicator> by {{#tag:indicator}} - when considering all wikis, that's still quite some work, but I have the impression that it might be a few (order of 10?) templates per wiki at most. As such, it might not be a high-priority fix, despite being very visible in some cases (the Ptag template on mediawiki and the reported template issues on enwiki are good examples).

However, this is also a problem that we do not necessarily entirely detect with visualdiff, because it might only affect a link target in an indicator (this was the case for the Geo template, if I remember correctly).

I think there's a solid argument to make that {{#tag}} is the proper wikitext to use here, which expands the {{{1}}} in the context of the template before passing it to the extension tag. Having an extension tag reach into the parent context for its variables seems Wrong, and it's one of those things which make you wonder how it "ever" worked. I don't think it works for other templates, like <ref> (this would be interesting to test), it seems to be a weird misfeature of the fact that <indicator> is not "quite" an extension tag in some way.

That said, if we do decide that this is a Known Difference, we should resolve this task by creating a lint for it, not simply declining.

In T348722#10163197, @Izno wrote:

In T348722#9246523, @cscott wrote:

The thing is, this seems to work fine on enwiki, at least in my sandbox:
https://en.wikipedia.org/wiki/User:Cscott/T348722?useparsoid=1

The reported issue does show up on en.wp at AIV:

Hi @Izno, looks like that comes from https://en.wikipedia.org/w/index.php?title=Template:Floating_link&action=edit ... and per discussion here, could you change that to use the #tag: form for the indicator?

Sure. It doesn't look like there are many uses on en that would need something like this adjustment. However there are at least 800 fleetwide (that's just the template namespace and I would guess there are smatterings elsewhere as on en.wp).

That query lists every match twice for some reason. So the actual count is half that. Still probably worth a lint matching your global search.

I used a https://en.wikipedia.org/wiki/Wikipedia:AutoEd module ( https://en.wikipedia.org/wiki/User:Cscott/T348722-fixer.js ) to make edits on many of the affected pages. Some I didn't have edit rights to. This has knocked the total count down to the point where I think we could just add a simple Lint rule (for {{{ in <indicator>) to let the community tackle the rest.

Probably don't need a lint at this point, just convince a global interface editor (or maybe a steward) to fix the rest or something (and some of those will be fixed by fuzzybot it looks like), +- a specific tech news or something delivered to still-affected wikis?

Oh I guess I somehow forgot in the past 24 hour about the other namespaces. zzzz

While indicator is the most egregious case for this usage, @Arlolra thinks that other extensions (kartographer, poem, etc.) might potentially also have some breaking uses and that linting could expose them all. But, we'll consult and see what seems best.

Yeah, I'm also somewhat worried about regressions given that it may be up to 9 months before we actually turn on Parsoid read views on some of these wikis. So a lint will help ensure that more instances of this don't (re)appear.

https://en.wikipedia.org/wiki/User:Cscott/T348722#Worklist now shows a very reasonably-small set of pages with <indicator> issues related to this task. Most of the rest are templates which are protected in some way that makes it impossible for me to edit them. Hopefully those admins will be prodded by the lint.

Change #1186956 had a related patch set uploaded (by OSleger; author: OSleger):

[mediawiki/services/parsoid@master] Linter: Add lint for usage of template arguments inside tags

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

Change #1186986 had a related patch set uploaded (by OSleger; author: OSleger):

[mediawiki/extensions/Linter@master] Add lint category template-arg-in-extension-tag

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

Documentation of lint: https://www.mediawiki.org/wiki/Help:Lint_errors/template-arg-in-extension-tag

Change #1189192 had a related patch set uploaded (by OSleger; author: OSleger):

[mediawiki/core@master] Add lint category template-arg-in-extension-tag

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

Change #1186986 merged by jenkins-bot:

[mediawiki/extensions/Linter@master] Add lint category template-arg-in-extension-tag

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

Change #1189192 merged by jenkins-bot:

[mediawiki/core@master] Add lint category template-arg-in-extension-tag

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