In T212071#8274383, @Legoktm wrote:

Scripts to fix: https://global-search.toolforge.org/?q=%22scribunto-console%22&namespaces=2%2C4%2C8&title=%28Gadgets-definition%7C.*%5C.js%29

I have now applied the fix to all of the above pages, so I am closing this issue.

I found the following affected pages from global search:

Ok, I have now patched all affected scripts, so I'm closing this task. Thanks everyone for your help.

I found a problem with T300743-enwiki2.patch - disabling and uninstallation was broken for imports containing escaped characters, as they were searching for the unescaped script name instead of the escaped script name. I've fixed this in T300743-enwiki3.patch below. I'm confident that the patch is working properly now, so if everything looks good I will go ahead and roll it out. @Enterprisey, does this look OK to you?

Here's the new patch:

In T300743#7686298, @MrStradivarius wrote:

However, if you then normalise the import for that script, the gadget will then parse it from common.js without decoding it, and then double encode it when it saves the page, so you will get foo\\\'bar.js.

In T300743#7677493, @Enterprisey wrote:

I believe the line terminator characters are not allowed to be in MediaWiki page titles, so if it's not too much extra effort I'd suggest rejecting them outright (crashing or alert()'ing would be fine, the installation links would have to be severely broken anyway).

I've tested the patch, and there is a problem with it - it breaks round tripping between the common.js and the gadget. If a script name contains a single quote like foo'bar.js, when saving it to common.js it will be escaped as foo\'bar.js, which is correct. However, if you then normalise the import for that script, the gadget will then parse it from common.js without decoding it, and then double encode it when it saves the page, so you will get foo\\\'bar.js. This will break the import, as that is a different MediaWiki page title than the original script name.

I've created a patch for the enwiki gadget. @Enterprisey: how does this look to you?
I haven't tested the patch locally yet - I'll do that after work.

Thanks for making the patch. I had a look at it, and I think that the URL needs to be escaped differently, with URL encoding instead of JS string escaping. In fact, there are four different contexts here, that each require different escaping:

I have global interface admin rights now, so I can patch all of the affected wikis. It will take me a little while to get the patches ready, though, and it's too late here for me to do it today.

I'm finding the following instances of the gadget using this global search query:

In T29766#7613238, @SD0001 wrote:

By default, I think gadgets should be treated as safe.

I had a look with the global search tool and couldn't find any more instances, so I think we're now actually safe to close this issue. Feel free to reopen if you find any others.

@Urbanecm Yes, those all look good to me. Thank you!

@Urbanecm I've made patches for the instances that @sbassett found. Could you apply these as well?

I think I applied all of them correctly -- can you check that please?

@Urbanecm I made patches for each of the listed wikis. If you could apply them, it would be much appreciated.

Hm, it might be best if I ask for global interface admin permissions - then I can just update them all myself. I had those permissions previously for a multi-wiki maintenance task, so hopefully I will be able to get them again.

Will user subpages be included? The first of the acceptance criteria above is not clear on this point.

I just managed to delete the file using the normal web interface.

I'm reopening this. @Pokefan95: the issue does seem to be the same as at the other bug, but the page still needs to be deleted. That will require help from someone with access to the database, I'm guessing. I just tried to delete it again today, and it failed with the same error, so it doesn't look like waiting will help things.

In T136375#2335622, @MrStradivarius wrote:

This was also affecting my ConfirmRollback script.

This was also affecting my ConfirmRollback script. If you have the script installed and click on a rollback link on a page that you have set to "confirm", then the script will pop up a dialog saying "Revert n edits by SomeUser?" After the change, the rollback would occur directly after the initial click on the rollback link, regardless of the dialog.

In T129764#2138147, @Catrope wrote:

Could not load notifications from xxx.org. This may be caused by an ad blocker or other browser extension blocking the request.

I also agree with @Jay8g that it would be good to do something about the notification being stuck in the menu with no obvious way to dismiss it. If the notification could link to the proper page on the remote domain that would work, if that is possible with the current architecture. Dropping the notification after one view would also work. One of those options plus a descriptive error message would be the sweet spot for this particular issue, I think.

In T129764#2115370, @Quiddity wrote:

I believe this is caused by the NoScript browser extension, and you just need to whitelist the domain.

In T114384#1927029, @Qgil wrote:

Was this topic discussed at the Summit?

In T119735#1905272, @hoo wrote:

I don't think there's anything we can do in Wikibase to "fix" this and I'm not sure Flow should mess with the title used for parsing either. It might be a good idea to also use a random Topic: namespace title during comment previews in flow, but despite of that, I don't think this is actionable. Wontfix?

The direct cause of this error message is the logic in d:Module:Property documentation. On line 262 it assumes that the global variable id exists if the Wikibase entity returned by mw.wikibase.getEntity also exists on line 257. However, if no id is supplied as an argument to the module, the module is not invoked in the "Property talk" namespace, and mw.wikibase.getEntity(nil) returns the entity for the current page, then the id variable will be nil, and the Wikibase entity will exist. This will result in the error that you saw when the module tries to concatenate id to the URL string in line 262.

You need to put safesubst in the template you are trying to substitute as well. In Vorlage:en, change {{#if:{{{nolink|}}}|Englisch|[[Englisch]]}} to {{<includeonly>safesubst:</includeonly>#if:{{{nolink|}}}|Englisch|[[Englisch]]}}, and it should work.

To add to what Anomie and Jackmcbarn said, if you do need to use frame:preprocess with both substitution and transclusion, you can use safesubst. For example, frame:preprocess( '{{safesubst:Test}}' ) will always get you the expanded {{Test}} template.

In T14974#1799933, @cscott wrote:

I'm just saying that you can't "fix this bug" without fixing the content first.

In T114384#1754743, @Qgil wrote:

This task is mainly about agreeing on expectations on the developers changing APIs, right?

In T35355#380446, @Krinkle wrote:

(In reply to comment #5)

Well, if we're talking about a new feature. Then I don't think there's a need
to support user scripts (if that's possible in a good way at all).

If you're referring to /* [[links]] */ and Special:WhatLinksHere.. well, I'd say keep
using that until gadgets are the common way for creating scripts.

In T114384#1720920, @Legoktm wrote:

The procedure for api.php deprecation and updates is documented at https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap (could be moved to a better page I suppose).

In T114384#1720147, @Qgil wrote:

At the Developer Summit, we should decide whether...

In order to reach to such decision at the Summit, what would need to start being discussed now?