If I understand the intention of the task and the logic in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/749580/5/includes/skins/Skin.php#153 correctly, it is missing && !$this->getRequest()->getRawVal( 'oldid' )

In T233520#7523405, @Manuel wrote:

Hi everyone! Does T295219 mean that we didn't solve the problem after all?

There were 235 pages listed on https://sv.wikipedia.org/w/index.php?title=Special:UnconnectedPages&limit=250&offset=0&namespace=0

In T284921#7156564, @ssastry wrote:

span.tocnumber { display: none; } should do it right?

There are no links on MediaWiki:Gadgets-definition

This was resolved in T266298.

Sounds like this can be done with a throttle set to page. See https://www.mediawiki.org/wiki/Extension:AbuseFilter/Actions#Throttling

Hey, @Zabe! Thank you so much for taking a look at this, and so quickly too! I'm unsure if this should be added to wgSemiprotectedRestrictionLevels too. I'm not sure what that does, but the other projects that have extendedconfirmed also have that listed in wgSemiprotectedRestrictionLevels. I'll defer to @Urbanecm on this one.

Oh, and the file is https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/InitialiseSettings.php

Maybe I should also add that the filter has correctly ignored actions that are sparse enough for the filter's throttle.

In T258895#6925835, @Legoktm wrote:

This is waiting on response from the WCQS maintainers on whether the above criteria are met (now documented at https://wikitech.wikimedia.org/wiki/W.wiki)

async function is part of ECMAScript 2017 ("ES8").

Is there a list of all patches merged in 1.36.0-wmf.34?

@Krinkle This feels a lot like T173411

Going through Flow patches in 1.36.0-wmf.34 we find https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/668777/ but that looks unrelated to me, which makes me believe that the error is in some other extension or core.

When I reported this, the bug did not manifest on svwiki like https://sv.wikipedia.org/w/index.php?title=Wikipediadiskussion:Flow&action=history but now it's on svwiki too, which means the fault is in 1.36.0-wmf.34

...but this is still strange. From https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/actions/HistoryAction.php

omg, I figured it out: So, Flow does not load mediawiki.interface.helpers.styles at all. VisualEditor does. From https://phabricator.wikimedia.org/diffusion/EVED/browse/master/extension.json

"dependencies": [
	"ext.visualEditor.core",
	"ext.visualEditor.mediawiki",
	"ext.visualEditor.diffing",
	"mediawiki.Title",
	"mediawiki.interface.helpers.styles",
	"mediawiki.user",
	"mediawiki.util",
	"mediawiki.jqueryMsg",
	"mediawiki.storage",
	"mediawiki.pulsatingdot",
	"mediawiki.skinning.content.parsoid",
	"mediawiki.widgets",
	"ext.visualEditor.switching",
	"ext.visualEditor.welcome",
	"oojs-ui.styles.icons-editing-advanced"
]

If the user unchecks "Enable the visual editor and the new wikitext mode in Structured Discussions" in https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-editing and then goes to https://www.mediawiki.org/w/index.php?title=Talk:Compatibility&action=history the parens aren't there.

I've tried my best to investigate this, without any luck. Part of that might be because I'm not familiar with less. What I've found is:

• .comment--without-parentheses is defined in https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.interface.helpers.styles.less

I'm assuming that the problem and solution is the same as T137383 / https://gerrit.wikimedia.org/r/294701

T259019 and T259028 were also closed as duplicates of T258277.

T259099 was closed as a duplicate of T258277, so I'm assuming this is intentional.

That's amazing, Catrope!

On second thought: Forget about wgServer and wgServerName. Just give us location.host which differentiates between desktop and mobile.

If I am to investigate a technical problem I need:

1. Wiki (wgServerName)
2. Browser (navigator.userAgent)
3. skin
4. wgAction
5. wgNamespaceNumber
6. Any JavaScript error
7. Any special page (wgCanonicalSpecialPageName)

I do believe this was declined in T152731.

Does this task also cover the fact that there are two radio inputs in a row on intermediate revisions, or should I open a new task about that?

This is not necessarily something I personally recommend, but some projects load scripts from the user namespace in the MediaWiki namespace. An okay-ish example would be this search on enwiki and then searching on the page (ctrl-F) for User:. This finds for example https://en.wikipedia.org/wiki/MediaWiki:Gadget-wikEdDiff.js that imports https://en.wikipedia.org/wiki/User:Cacycle/wikEdDiff.js

In T272104#6770997, @gerritbot wrote:

Change 657953 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] resourceloader: Allow modules to mark themselves as ES6-only

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

Or just remove ⟨red-link-title⟩

I think the only possibly legitimate reason to do this would be to get the title without " (page does not exist)" for redlinks. See for example https://sv.wikipedia.org/wiki/MediaWiki:Gadget-MarkDeletedPages.js and https://sv.wikipedia.org/wiki/MediaWiki:Gadget-NormaliseraSignatur.js that have to remove " [inte skriven än]". The fact that some user scripts may modify the title attribute is not a good enough reason to do this, in my humble opinion, as the same script could just as easily modify the data attribute as well.

Same as T178356?

@Niteshyadav585 https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/parser/Parser.php

What system message would be different in Indian English compared to British English?

The category https://en.wikipedia.org/wiki/Category:Pages_with_non-numeric_formatnum_arguments is being populated but it is not listed on https://en.wikipedia.org/wiki/Special:TrackingCategories. How is this possible?

I think someone or something turned 8 to 80 in namespaces in the URL to global-search.toolforge.org above. Let's see if this works instead: https://global-search.toolforge.org/?q=\%24.%2B\%3C(div|span|form|p|a|label|table|tr|th|td|th|thead|tfoot|tbody|small|strong|em|i|b)[^%3E\n]*%2F\s*%3E[^\n]*\%3C&regex=1&namespaces=8

Why do some of the test urls go to mediawikiwiki if this task is about cawiki? For example the first one with blockOptions. If I enter

mw.loader.load( 'https://meta.wikimedia.org/w/index.php?title=User:Mike.lifeguard/blockOptions.js&action=raw&ctype=text/javascript' );

in the console on https://www.mediawiki.org/wiki/Topic:Vlxq3or3tf4p1ozv I get "Uncaught ReferenceError: wgCanonicalSpecialPageName is not defined", just as the task says, but that is because mediawikiwiki has turned off global JavaScript variables (T72470). That does not happen on cawiki.

They aren't used anywhere in the cawiki User namespace either:
blockOptions
addTools
TwinkleGlobal

After a quick investigation, none of the following seem to be used anywhere in the cawiki MediaWiki namespace:
blockOptions
addTools
TwinkleGlobal

@daniel , @BPirkle is this because of MCR / T212428 / 9bd04f784566?

svwiki used to be in report-only. It no longer is. It has broken recently (this year). None of the patches I link to indicate that this is intentional.

https://deployment.wikimedia.beta.wmflabs.org/wiki/Main_Page has a content-security-policy header, but no content-security-policy-report-only header.

Maybe I should add that this worked in January. There are two CSP-related patches to CommonSettings since then. First https://phabricator.wikimedia.org/rOMWCa31cfb5a177a2cebbf786f74bdde604458a9867c on February 25 and then https://phabricator.wikimedia.org/rOMWC203f468dcdf3f07aa6f2c25bd7486861f8a95af4 on March 16. Neither patch makes any mention of removing the existing report-only for production wikis in their commit messages.

In T254698#6200231, @Reedy wrote:

Is it possible to enforce prevention of external scripts while keeping everything else report-only?

What do you mean by everything else?

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596756/ allegedly caused T254546.

Not specific to Vector.

See also T254550.

See also T254546.