In T338230#8999631, @Poslovitch wrote:

Did a bit of investigation.

This "incompatibility" comes from esversion being > 6 and esnext: true. In ACE's JavaScript worker (https://github.com/ajaxorg/ace/blob/master/lib/ace/mode/javascript_worker.js), which I guess we're using due to https://gerrit.wikimedia.org/r/#/q/I263e08a39712279a06b12cd75ebedcccaf191b58 overriding its maxerr option, the esnext option is set to true: https://github.com/ajaxorg/ace/blob/ceb38532bf73f06508e5399c6635d2cc312b1352/lib/ace/mode/javascript_worker.js#L82.

I don't know how to fix this reliably if any esversion > 6 is used, but I guess it would imply setting esnext to false.

Yeah, this works, thanks:

// jshint esnext: false
// jshint esversion: 11

Too bad JSHint doesn't support esversion > 11, so I can't use e.g. ||= without triggering a linter error.

In T349653#9292619, @DLynch wrote:

Which I think might be always happening on talk pages now regardless of how many of the sub-features are disabled. I checked, and turning off everything in the preferences still leaves the mw.dt object existing from the dt.init JS.

OK, thanks.

Oh, that's great news. (Currently a fragment with random characters gives a notification "This comment could not be found. It might have been deleted or moved." – is that expected? Also maybe unsuccessful lookup should be reflected in the notification text as well.)

In T348893#9258371, @Jdlrobson wrote:

@Jack_who_built_the_house is there a page with an OOUI button that is triggering a popup that we can use for QA?

That's an interesting question, because I stumbled upon this when I was testing a script of mine that is not in production yet. And even there the button should be outside of #mw-content-text which the link selector requires.

...Because in a later commit making mw.widgets.CopyTextLayout.js based on an OOUI widget this change has been erased.

So why UrlShortener still uses the articles icon?

@Krinkle Thank you for caring enough to look into old copies of my script, haha. The majority of the results are not used by anyone. Those in my userspace are kept for historical purposes. I already requested removal of some of them. If they interfere with your cleaning up routines, I can remove all or most versions that are not in use.

@Jdlrobson Convenient-Discussions now uses the hook, thank you for implementing it.

So, if "the hook wikipage.tableOfContents.vector does not seem to have been adopted by any gadgets or code" that basically means that either

1. there are no user scripts in nature that modify the TOC
2. or their maintainers are unaware of the creation of the hook => their user scripts work unreliably in Vector 2022.

The second seems more realistic to me, so I would look for such user scripts and inform their maintainers.

I completely missed the moment when this was implemented, so my code still uses a hack. I'll check out the hook shortly.

The workaround advised to me by @AntiCompositeNumber is to open a URL with some tag instead of the master branch. You can take any from https://phabricator.wikimedia.org/source/mediawiki/tags/master/, e.g. https://doc.wikimedia.org/mediawiki-core/1.40.1/js/. P.S. I see he already said that, well I'll keep it as an instruction anyway.

It happens on a regular basis. Like the third time I run into it in the last week. The docs go down for a few hours, then resurface. Feels like when something is doing rm -rf, then reuploading the data.

The easiest possible improvement:

In T303541#7767908, @Esanders wrote:

pages with h3/h4 topics often have higher level headings which group those topics, but which shouldn't be subscribable:

Right, and wikis often use H1 headings for days/weeks/months in such cases as a workaround.

Please attach restricted files

In T345490#9143342, @Jdlrobson wrote:

Correct. It's up to the gadget to detect menu support first.

I think this is a classic "developer logic vs user logic" problem. From the user's (gadget developer's) POV, "Please update call to mw.util.addPortletLink with ID p-namespaces. Use p-associated-pages instead." means exactly that: replace all usages of p-namespaces with p-associated-pages. The user likely won't even notice that this warning comes from the Vector 2022 skin, assuming the instruction to be universal.

The local solution is simple – choose the first findable portlet like document.getElementById('p-associated-pages') || document.getElementById('p-namespaces') || document.getElementById('p-cactions'), see https://en.wiktionary.org/wiki/Project:Grease_pit/2023/September#Fix_MediaWiki:Gadget-DocTabs.js. So I close this. But the very need to use such a tricky way hints a poor architecture IMO, see T345490#9138919.

It turned out there's not only a race condition; on pages like https://en.wiktionary.org/wiki/Citations:house the execution of the script stops with error

In T345490#9138522, @Jdlrobson wrote:

Please see the error console.

It says: "Please update call to mw.util.addPortletLink with ID p-namespaces. Use p-associatedPages instead."

1. The new element has ID p-associated-pages (with a dash, not camelCase); using p-associatedPages doesn't have any effect.
2. If you follow this advice, your item won't be added on Vector and Timeless which still have p-namespaces.
3. The code mapping #p-namespaces to #p-associated-pages may cause a race condition if the script is smart enough to specifically look for the existence of #p-namespaces before adding its item (see T345491). (Update: and even break some things completely, see T345491#9138953.)

Why not just make sure all skins use the same IDs and do backwards compatibility by centralized means (in mw.util.addPortletLink() itself perhaps) instead of having pieces of code all around struggling to make sense of each other? (Otherwise, how is the update to p-associated-pages T316908 supposed to carry on? Will each skin have this mapping code that fixes one thing, breaks another?)

I'm lazy to create another task, but OOUI in general doesn't seem to account for the sticky header. The same with $floatableContainer of OO.ui.PopupWidget:

At least the class vector-tab-noicon should be added to the <li>, I assume.