cite_references_link_one
53 local overrides currently exist.

• 38 remove the parameter $4. This doesn't make much sense. The parameter is mostly for a dir="…" attribute, see T15673. It was added in 2012. The overrides that miss the parameter are probably older and just never updated.
• 32 remove the <span class="mw-cite-backlink">. As above, this doesn't make much sense and is most certainly only because these overrides have never been updated. The feature was added in 2012 via T34626.
• 2 wikis (frwiki, frpwiki) add a class="noprint". This is most certainly pointless. The mw-cite-backlink class mentioned above is supposed to do that. Again, the overrides are just outdated (both from 2007) and never updated.
• frpwiki adds a hard-coded id="rèferences_vers_lo_tèxte" to every <li>. This is just wrong and not how HTML works. It's not even possible to reliably use this anchor to jump to the first list element because pages can contain more than one reference list. frwiki once did the same but was fixed in 2019. frpwiki needs to be updated the same way.
• 35 wikis add ''' or <strong> or <b> to make parts bold. This should be done with CSS. The class mw-cite-backlink mentioned above was added exactly for that.
• 41 change the symbol ↑ to ^.
• 3 change the symbol ↑ to ▲. All 3 are vi wikis. 2 more vi wikis exist but don't use the same symbol for an unknown reason.
• enwiktionary adds spaces that are most certainly meaningless or should be replaced with CSS.
• ruwikivoyage removes the backlink entirely (example). This really doesn't make any sense, interferes with what readers need to be able to do with references, and should just be impossible to do.

That's great to hear. Thanks a lot for the extra effort!

We decided to close this as being done and track the remaining issues in separate tickets:

1. The edge-case I described above is now tracked in T369801: VE doesn't show parent reference on a subreference that is a reuse by name. This is not a blocker for our plan to do more user tests.
2. We will iterate on the design. This can happen any time later.

Finally deployed on the cluster:

@Plenz Please let us know if we should have a look at the source code and where to find it, or if there is something else left where we can help. Otherwise we would like to resolve this task as being done.

I was under the impression that dewiki also usually used {{Cite book}}

When I look into the code of the AntiSpoof extension the only piece of code I can find that is directly related to renaming users is a DELETE. It deletes the old row with the old username from the spoofuser table. I can't find anything that looks like it would intentionally keep track of old usernames. Where does this code live? Or does this imply that the DELETE I found is broken and old usernames get blocked indefinitely by accident? Why does it show the new username then?

My best guess at the moment is that somebody holds a local reference to the entire MediaWikiServices instance. But there is a chance that gets destroyed and rebuild. The old instance gets reported as "Container disabled!" then. Example CodeSearch: https://codesearch.wmcloud.org/search/?q=%3E.*%3D.*Services%3A%3AgetInstance%5CW*%3B&files=%5C.php%24. I will start cleaning up a few of these places.

On https://gerrit.wikimedia.org/r/1020276 in the FileImporter extension we currently get CI failures as well. While not identical they sound very similar. For future reference:

1) Flow\Tests\Collection\PostCollectionTest::testGetCollection
14:36:46 Wikimedia\Services\ContainerDisabledException: Container disabled!
14:36:46 
14:36:46 /workspace/src/vendor/wikimedia/services/src/ServiceContainer.php:403
14:36:46 /workspace/src/includes/MediaWikiServices.php:354
14:36:46 /workspace/src/includes/MediaWikiServices.php:1653
14:36:46 /workspace/src/includes/ServiceWiring.php:2406
14:36:46 /workspace/src/includes/user/UserGroupManager.php:908
14:36:46 /workspace/src/extensions/Flow/includes/TalkpageManager.php:210
14:36:46 /workspace/src/extensions/Flow/includes/TalkpageManager.php:84
14:36:46 /workspace/src/extensions/Flow/tests/phpunit/PostRevisionTestCase.php:226
14:36:46 /workspace/src/extensions/Flow/tests/phpunit/Collection/PostCollectionTest.php:30
14:36:46 phpvfscomposer:///workspace/src/vendor/phpunit/phpunit/phpunit:106
14:36:46 === Logs generated by test case
14:36:46 [objectcache] [debug] MainWANObjectCache using store {class} {"class":"HashBagOStuff"}
14:36:46 [localisation] [debug] LocalisationCache using store LCStoreNull []
14:36:46 [DeferredUpdates] [debug] DeferredUpdates::run: started MediaWiki\Deferred\MWCallableUpdate_MediaWiki\User\UserGroupManager->addUserToGroup #{updateId} {"updateId":33324}
14:36:46 [DeferredUpdates] [debug] DeferredUpdates::run: ended MediaWiki\Deferred\MWCallableUpdate_MediaWiki\User\UserGroupManager->addUserToGroup #{updateId}, processing time: {walltime} {"updateId":33324,"walltime":0.0007109642028808594}
14:36:46 [MessageCache] [debug] MessageCache using store {class} {"class":"HashBagOStuff"}
14:36:46 [wfDebug] [debug] ParserFactory: using default preprocessor {"private":false}
14:36:46 [DeferredUpdates] [debug] DeferredUpdates::run: started MediaWiki\Deferred\MWCallableUpdate_MediaWiki\User\UserGroupManager->addUserToGroup #{updateId} {"updateId":42501}
14:36:46 [DeferredUpdates] [debug] DeferredUpdates::run: ended MediaWiki\Deferred\MWCallableUpdate_MediaWiki\User\UserGroupManager->addUserToGroup #{updateId}, processing time: {walltime} {"updateId":42501,"walltime":0.0006711483001708984}
14:36:46 [localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one []
14:36:46 [objectcache] [debug] fetchOrRegenerate(wikidb-unittest_:linktargetstore-id:3%3ATest): miss, new value computed []
14:36:46 [BlockManager] [debug] Block cache miss with key BlockCacheKey{request=#33988,user=#41973,primary} []
14:36:46 [CentralAuth] [debug] Loading state for global user {user} from DB {"user":"Flow talk page manager"}
14:36:46 [DeferredUpdates] [debug] DeferredUpdates::run: started MediaWiki\Deferred\MWCallableUpdate_MediaWiki\User\UserGroupManager->addUserToGroup #{updateId} {"updateId":41970}
14:36:46 [DeferredUpdates] [debug] DeferredUpdates::run: ended MediaWiki\Deferred\MWCallableUpdate_MediaWiki\User\UserGroupManager->addUserToGroup #{updateId}, processing time: {walltime} {"updateId":41970,"walltime":0.0006620883941650391}
14:36:46 ===
14:36:46 
14:36:46 2) Flow\Tests\Collection\PostCollectionTest::testNewFromId
14:36:46 Wikimedia\Services\ContainerDisabledException: Container disabled!

• I'm not sure but I think this is a misunderstanding. We don't have access to the source code. https://toolsadmin.wikimedia.org/tools/id/osm4wiki doesn't mention anything.
• This is unrelated, but I think it would be cool to add the tool to the new https://toolhub.wikimedia.org.
• I think the scrollbar is because of a div.check { height: 100%; } in the CSS. This is the list with the checkboxes below the toolbar. The height for this element can only be 100% minus the height of the toolbar above.
• Personally, I would expect popups similar to the ones rendered by Maps (Kartographer), with a link to the article. Here is an example. But you are obviously free to shape this however you want. Maybe it's better to not do anything on click and instead rely on the highlighting that already happens in the list?
• Templates like AllCoordinates are in the hands of the community. We don't know much about these. Personally I think a "report a bug" link directly in the tool is your best option to get feedback directly from the users of the tool.
• I'm afraid there is nothing we can say about kmlexport. Again, https://toolsadmin.wikimedia.org/tools/id/kmlexport doesn't contain any information other than the names of two people. Can you try to contact them?

So far we can only review the user interface and how it behaves. This is what we noticed:

• In Chromium based browsers the page does have a scrollbar on the very right. It only scrolls down a few pixels. While this is not a big problem it can be a bit distracting when I use the scrollbar in the list on the left side of the screen. This doesn't happen in Firefox.
• Clicking any of the pins on the example maps opens what we believe is an alert() popup with the text "marker [object Object]". This typically happens when a function expects a string but gets fed with a more complex object instead. The browser's JavaScript engine tries to convert the object to a string, but can't find a dedicated method and instead falls back to "[object Object]" as some kind of error message. This happens in all browsers.
• While there is a stop button to stop the progressive loading in one of the examples, there is apparently no way to continue it.
• We are a bit confused what the purpose of the checkboxes is. They don't seem to do much other than hiding individual pins. This seems unnecessary especially when there are only very few pins on the screen.
• One feature we are missing is a button to reset the zoom and go back to the initial position and zoom factor where all pins are visible.

I'm not sure I understand the user story behind this. This is a preview in the context of VisualEditor's editing UX. Not the Popups extension. Interacting with the content in the context of VisualEditor is done via the "Edit" button.

I know this is probably to much to ask for. But personally I'm not a fan of such inverted "say yes when you meant to say no" checkboxes. I find these unnecessarily confusing. It's almost a dark pattern in some situations. Do you think we can do something about this?

In safe-mode you can (painfully) see that the <area> tags we're outputting aren't aligned […]

You can use the tab key and let the browser highlight the areas.

When comparing
https://ru.wikipedia.org/wiki/Template:Интерактивная_схема_Московского_метрополитена?useskin=vector&safemode=1 and
https://ru.wikipedia.org/wiki/Template:Интерактивная_схема_Московского_метрополитена?useskin=vector-2022&safemode=1
we can see that the image renders in two different sizes. It should be 270px but is 262px in the new skin.

I don't think it can be an issue with the SVG rendering because it would be equally broken in all skins then.

Sorry, my comment was not very helpful. What probably happened is that some of the code (CSS?) in the gadget is a little fragile and starts to behave odd depending on the skin. It's entirely possible that such issues are invisible for a very long time and only become visible much later together with seemingly unrelated changes in MediaWiki, skins, or extensions. Still I suspect the issue is probably in the gadget and needs to be fixed in the gadget.

I might be wrong, but as far as I can see this has nothing to do with MediaWiki, but is a community gadget: https://ru.wikipedia.org/wiki/MediaWiki:Gadget-ondemand-imagemapHighlight.js. The skin has no knowledge about this.

I unchecked one of the checkboxes above. The edge case we found is:

A<ref extends=book name=p20>p. 20</ref>
B<ref name=p20 />
C<ref extends=book name=p20 />
<references>
<ref name=book>book</ref>
</references>

This mostly works, with one exception. The ContextItem popup should be the same in all 3 cases, but doesn't show the parent on B. Apparently we created some code that relies on the extends= attribute being there. But this is not guaranteed when it's a reuse via name=. I wonder if this is worth a separate ticket?

Thanks a lot! I believe I missed the "-labs" in the file name and wanted to be on the safe side. Looking back now it makes sense that this was really only affecting the beta cluster.

That's mostly because the project is unfinished and doesn't do anything. T163921 and many of the subtasks are still open. T161527 contains most of the information you are probably looking for. I also find T176764 quite interesting as it shows how this was meant to be used. But this never happened, as far as I can tell.

I had a brief look at the codebase and my first impression is that the entire extension is written with the assumption that "usernameattribute" is never anything but "uid", as well as – as a consequence of this (wrong?) assumption – that "usernameattribute" and "searchattribute" are always identical. I don't see an easy way to fix this.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

This appears to be an unused placeholder ticket from 5 years ago. Please feel free to reopen it in case you still need it.

Unfortunately testing this is exceptionally hard for at least two reasons.

• For some reason clicking the red category link at the bottom doesn't go to the category page as it used to. It appears like somebody had the idea to redirect this directly to VisualEditor. Unfortunately this doesn't make much sense on category pages. A category doesn't need content to be useful. Directly switching to VisualEditor makes it impossible to see what's in the category. I would like to find out which team is responsible for this behavior and ask them to enable it only in specific namespaces.
• The Parsoid code path currently doesn't set a tracking category. I don't know what dictates the behavior of a category on the beta cluster. The old or the new parser? We might need to make the two behave the same to make this behave more consistent.

We will talk about the necessary next steps in demo time, I guess.

Absolutely, thanks. That will certainly be something to look into when we find the time and resources. But it can only work when both sides use the same hook system.

This is the most minimal example I was able to extract that demonstrates the problem.

<ref><phonos file="De-Deutschland.ogg" /></ref>

MediaWiki-extensions-Phonos renders this as an <a> tag with a href="….mp3" attribute as a fallback for browsers without JavaScript and a mouse click handler for browsers with JavaScript. The Reference Previews code copies the HTML but not the JavaScript handler. This is by design. Reference Previews can't know what it will find in a <ref> and if there are interactions that might or might not make sense in a popup. Remember, the content of a <ref> is essentially a separate wikitext document that can contain literally everything. We really don't want Reference Previews to blindly copy and trigger unknown JavaScript handlers, but only support features that are known to be safe and useful inside of a popup.

Moved to T366324#9866856.