Tentatively adding as a deployment blocker, because IIRC the exact same thing has happened in the past, and people complained about it a lot.

In T288739#7353327, @Krinkle wrote:

wmf.21 (nl.wikipedia)	wmf.23 group0 (mediawiki.org)

It seems […] the portlet HTML format has changed again which broke a gadget. […], I suppose it would be a good time to double check whether the CSS is backward-compatible with at least the last two weeks of cached HTML generated by Vector itself (ignore my gadget for now), as otherwise this glitch might affect other parts of the interface for people after tomorrow.

In T288739#7353363, @Jdlrobson wrote:

It also seems like maybe the portlet HTML format has changed again which broke a gadget.

This is being worked on as part of T289163.

Thanks for the report.

The Twinkle code appears to use a custom function Twinkle.addPortletLink that replicates portlet HTML. The HTML is no longer consistent with Vector, which uses a vector-menu-dropdown-noicon class to distinguish between dropdown menus with icons and without.

There are 151 scripts impacted. 69 in the MediaWiki namespace.

We could add temporary support for this, or simply update the gadget code. I've fixed test wiki https://test.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-Twinkle.js&type=revision&diff=480994&oldid=480741,

My concern with temporary support is it will likely never be addressed and we'll end creating more work for ourselves, eventually needing to fix the scripts anyway, so personally, I'd rather just go in and manually update all the Twinkle scripts if that's what it takes. There may be other gadgets with the same problem, but we can make a User-notice today in preparation for that so gadget authors know what to do.

Either way, I don't think this needs to block the train. I can make sure group 1 wikis are not impacted by the end of the day, and fix the group 2 wikis by the end of tomorrow.

@ovasileva what do you think?

Additional note:

suppose it would be a good time to double check whether the CSS is backward-compatible with at least the last two weeks of cached HTML generated by Vector itself

It's backwards compatible with the more and variants menu so this is only a problem for gadgets which are creating menus in a non-standardized way. Perhaps a mw.util.addPortlet method needs to be provided if we want to service those users better.

After broadening the filter, I can see that actually only 15 scripts are impacted in the MediaWiki namespace:
https://global-search.toolforge.org/?q=Twinkle%5C.addPortlet+%5C%3D.*mw-portlet+vector-menu+vector-menu-.*type+%3D%3D%3D+%27menu%27+%5C%3F+%27dropdown%27+%3A+%27tabs%27&regex=1&namespaces=8&title=

In T290994#7353602, @Jdlrobson wrote:

Thanks for the report.

The Twinkle code appears to use a custom function Twinkle.addPortletLink that replicates portlet HTML. The HTML is no longer consistent with Vector, which uses a vector-menu-dropdown-noicon class to distinguish between dropdown menus with icons and without.

There are 151 scripts impacted. 69 in the MediaWiki namespace.

We could add temporary support for this, or simply update the gadget code. I've fixed test wiki https://test.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-Twinkle.js&type=revision&diff=480994&oldid=480741,

My concern with temporary support is it will likely never be addressed and we'll end creating more work for ourselves, eventually needing to fix the scripts anyway, so personally, I'd rather just go in and manually update all the Twinkle scripts if that's what it takes. There may be other gadgets with the same problem, but we can make a User-notice today in preparation for that so gadget authors know what to do.

Either way, I don't think this needs to block the train. I can make sure group 1 wikis are not impacted by the end of the day, and fix the group 2 wikis by the end of tomorrow.

@ovasileva what do you think?

I agree that this should not be a train blocker. Given that it's only the 15 scripts above that are affected, let's go for the manual update to the scripts. If we find more later on, we can reconsider the option for temporary support.

The code for most Twinkle instances is stored in Git and is copied to on-wiki pages by an automated or semi-automated process. Changes not committed to the Git repository will be overwritten on the next update. Please make sure to submit patches when editing on-wiki Twinkle files.

I have done

• https://github.com/wikimedia-gadgets/twinkle/pull/1443
• https://github.com/wikimedia-gadgets/twinkle-core/pull/18

Thanks @AntiCompositeNumber that makes a lot more sense and now I see the Imported from github [https://github.com/wikimedia-gadgets/twinkle]. comment (side note: It would be great if Extension:Gadgets supported showing a big warning box at the top of such pages and/or made these read only!)

I merged the two PRs raised by @AntiCompositeNumber. For most of the other wikis, I believe the Twinkle instances have neither git repos nor active maintainers, so I would suggest going ahead with the approach of editing the onwiki pages directly. Note: in some cases like knwiki there's an incorrect "Imported from github" comment at the top which is a result of copy-pasting from the enwiki version.

How confusing... :-S

If you let me know when the script has updated the pages on wikis that use the Github version, I can go in and edit the remaining ones.

wikimedia-gadgets/twinkle (formerly called azatoth/twinkle) github repo is only used for updating Twinkle on enwiki and testwiki. So on other wikis, if there's a comment that says it's imported from that repo, the comment can be ignored.

This doesn't appear to only be for Twinkle; I'm not sure of the exact cause (I'm very sure it's not one of my scripts), but it seems some gadgets(?) on Commons seem to be having the same behaviour. Screenshot below:

In T290994#7359669, @Berrely wrote:

This doesn't appear to only be for Twinkle; I'm not sure of the exact cause (I'm very sure it's not one of my scripts), but it seems some gadgets(?) on Commons seem to be having the same behaviour. Screenshot below:

https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-editDropdown.js&diff=591651294&oldid=431891324

In T290994#7359768, @AntiCompositeNumber wrote:

In T290994#7359669, @Berrely wrote:

This doesn't appear to only be for Twinkle; I'm not sure of the exact cause (I'm very sure it's not one of my scripts), but it seems some gadgets(?) on Commons seem to be having the same behaviour. Screenshot below:

https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-editDropdown.js&diff=591651294&oldid=431891324

That fixed it, cheers.

Same Problem occured on Simple Wiki

There really should be core-provided JS module for adding a portlet dropdown in the current skin.

Since this is a visual issue it makes sense not to be a blocker, but a tech notice message would have been appreciated.

In T290994#7364077, @Strainu wrote:

Since this is a visual issue it makes sense not to be a blocker, but a tech notice message would have been appreciated.

I promised this on Tuesday, T290994#7353602 but forgot to follow through, sorry about that.. I have opened T291438 for next tech news.