Page MenuHomePhabricator

Remove legacy javascript globals
Open, LowPublic

Description

For readers of Tech News (October 2019):

Gadgets and user scripts can access variables about the current page in JavaScript. In 2015, this information was moved from global variables named wg* to mw.config. The old way via wg* global variables will be removed later this year.

To find out if a gadget or user script that you use is affected by this change, open the JavaScript console in your browser. If you see warnings like the below, then you are using a gadget or script that will stop working if the issue is not fixed:

Use of "wgPageName" is deprecated. Use mw.config instead.

The following may help with finding the problem script or with fixing the issue once once found:

If you want your wiki to be one of the first to try the new way that no longer has these global variables, leave a comment below. This can help find new issues that we may have missed. If your wiki choose to enable the new way, you can let us know to undo it if a problem is found.


Timeline
  • Add option to disable legacy globals: wgLegacyJavaScriptGlobals. – T30916, 49ce5de7d94 (MediaWiki 1.17 in 2011)
  • Add deprecation notices for accessing mw.config.get() when wgLegacyJavaScriptGlobals is enabled. – T58550, 24f84b08cf91ef (MediaWiki 1.25 in 2014)
  • Migrate usage and gradually disable on Wikimedia wikis:
    • Turn it off on test2.wikipedia.org. – T67011, bbfba08d31 (2014)
    • Fix the Collection extension to not depend on these. T177259
    • Turn it off on group0 wikis. (test.wikipedia.org, mediawiki.org, and read-only wikis)
    • Turn it off for developers and in Continuous Integration for code merges. (DevelopmentSettings)
    • Turn it off on Beta Cluster for all wikis.
    • Turn it off on group1 wikis. (mostly non-Wikipedia)
    • Turn it off everywhere. (+group2: Wikipedia)
  • Turn it off by default in MediaWiki core. – T35837 (in release 1.35)
  • Remove the feature. – (in release 1.36 or later)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Ahecht added a subscriber: Ahecht.Aug 20 2018, 9:03 PM

We're still cleaning up the mess caused by switching from Tidy to RemexHTML, and on larger wikis such as enwiki tech-savvy editors will still be needed to working on the hundreds of thousands of pages with broken rendering for the forseeable future. Breaking all the old scripts and gadgets "soon" (as specified in the Tech News blurb) would be a disaster. This is only compounded by the roll out of the Interface Administrator group later this month, which means that gadgets and scripts in the mediawiki namespace or in the namespace of inactive users will only be able to be fixed by the very small number of editors granted this permission.

Krinkle changed the task status from Stalled to Open.Jun 6 2019, 8:42 AM

Proposing to resume this project after the 1.35 cycle starts, in October 2019. With the step of turning off for all WMF wikis happening somewhere between January and May 2020, and in MW core for third-parties after that, to be part of the 1.35.0 release in June 2020.

Krinkle updated the task description. (Show Details)Jul 13 2019, 12:25 AM

Change 524594 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] DevelopmentSettings: Disable legacy javascript globals in CI and for devs

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

Change 524594 merged by jenkins-bot:
[mediawiki/core@master] DevelopmentSettings: Disable legacy javascript globals in CI and for devs

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

I'm confused. Shouldn't it be set to false?

Indeed. Thank you for noticing :)

Change 524683 had a related patch set uploaded (by Krinkle; owner: Jforrester):
[mediawiki/core@master] Follow-up ffd802a386: Actually disable legacy JS globals

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

Change 524683 merged by jenkins-bot:
[mediawiki/core@master] Follow-up ffd802a386: Actually disable legacy JS globals

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

Change 541581 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] [Beta Cluster] Disable wgLegacyJavaScriptGlobals

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

Change 541581 merged by jenkins-bot:
[operations/mediawiki-config@master] [Beta Cluster] Disable wgLegacyJavaScriptGlobals

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

Krinkle added a comment.EditedOct 8 2019, 10:08 PM

For Tech News:

Gadgets and user scripts can access variables about the current page in JavaScript. In 2015, this information was moved from global variables named wg* to mw.config. The old global variables will be removed later this year. You can tell the developers if you want to try this out on your wiki first, at T72470.

I've added more details to the task description as well.

Krinkle updated the task description. (Show Details)Oct 8 2019, 10:17 PM

For Tech News:

Gadgets and user scripts can access variables about the current page in JavaScript. In 2015, this information was moved from global variables named wg* to mw.config. The old global variables will be removed later this year. You can tell the developers if you want to try this out on your wiki first, at T72470.

I've added more details to the task description as well.

I'm catching up on this: has it been done, or announced?

It has been done for DevelopmentSettings, Beta Cluster, group 0 and test2wiki. It has not been done for group 1 or group 2.

@Trizek-WMF The announcement still needs to be made yes. The change has not yet been deployed to wikis beyond beta and testing.

Krinkle updated the task description. (Show Details)Oct 24 2019, 2:42 PM

Thank you for your replies. I'm adding the call for testers on Tech News.

@Krinkle and @Nirmos, is there a schedule for the next groups?

The next group will happen some weeks after we have a few early adopters, which is what I'm hoping to get through Tech News.

Got it. Added to Tech News.

@Krinkle: I'm available if you want to deploy to svwiki.

Change 558621 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Disable wgLegacyJavaScriptGlobals on svwiki

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

Change 558621 merged by jenkins-bot:
[operations/mediawiki-config@master] Disable wgLegacyJavaScriptGlobals on svwiki

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

@Nirmos Sorry about the delay! The change has now been applied.

Before I applied, it I browsed around the svwiki's main page and several special pages and random articles and did not see any site-side scripts or gadgets that rely on the legacy feature. Let me know if you find any issues (either here, or on IRC or via wiki email, whichever you prefer).

Mentioned in SAL (#wikimedia-operations) [2020-02-12T20:38:55Z] <krinkle@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T72470 - Disable wgLegacyJavaScriptGlobals on svwiki (duration: 01m 08s)

Some before-and-after stats with regard to the number of global variables. This assumes Object.keys( window ).length and https://sv.wikipedia.org/wiki/Portal:Huvudsida

The old values were recorded on November 16 2019 and the new values just now. The odd thing is that logged out users now have more global variables than logged in users. I don't know how that's possible.

BeforeAfterDecreaseDecrease (%)
Logged in39123915238.9
Logged out37924113836.4
Nirmos added a comment.EditedFeb 12 2020, 11:04 PM

Found it. Redux and ReduxThunk exist while logged out, but not while logged in. No idea what that is.

Edit: Seems to be a dependency for hovercards, which makes sense.

Redux is this: https://en.wikipedia.org/wiki/Redux_(JavaScript_library)

It's apparently used by the Popups extension, which is apparently loaded for anons but not for logged in users.

I have been trying to see if we can deploy this in wikidata and Persian Wikipedia and I couldn't find any deprecation warnings when I opened several pages but is there a better way? For example sending a report to logstash in these cases (similar to CSP violations) or a codesearch in mwgrep?

@Ladsgroup I don't think there are any more uses in core or extensions. The main concern is gadgets and user scripts, so we need (technical) users to each look out for their own personal scripts and deprecation warnings they get.

Using an insource-search I see about 100 results on wikidata.org. But it's possible many of those are unused files (e.g. an import or skin that they no longer use).

@Ladsgroup I don't think there are any more uses in core or extensions. The main concern is gadgets and user scripts, so we need (technical) users to each look out for their own personal scripts and deprecation warnings they get.

Using an insource-search I see about 100 results on wikidata.org. But it's possible many of those are unused files (e.g. an import or skin that they no longer use).

I started a discussion in WD:PC and I will drop it in Monday. It should be okay given that it's deprecated six years ago and javascript is not part of stable interface policy.

Change 596180 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[operations/mediawiki-config@master] Disable wgLegacyJavaScriptGlobals on fawiki and wikidatawiki

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

Change 596180 merged by jenkins-bot:
[operations/mediawiki-config@master] Disable wgLegacyJavaScriptGlobals on fawiki and wikidatawiki

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

Mentioned in SAL (#wikimedia-operations) [2020-05-13T11:14:41Z] <ladsgroup@deploy1001> Synchronized wmf-config/InitialiseSettings.php: [[gerrit:596180|Disable wgLegacyJavaScriptGlobals on fawiki and wikidatawiki (T72470)]] (duration: 01m 06s)

Are we going to turn this off by default, at least, for 1.35? Or should we re-tag to 1.36?

I think flipping the default for the 1.35 LTS should be fine now, yeah, let's do it?

Change 617193 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Disable wgLegacyJavaScriptGlobals by default

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

Change 618030 had a related patch set uploaded (by Reedy; owner: Jforrester):
[mediawiki/core@REL1_35] Disable wgLegacyJavaScriptGlobals by default

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

Change 618030 merged by jenkins-bot:
[mediawiki/core@REL1_35] Disable wgLegacyJavaScriptGlobals by default

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

Change 617193 merged by jenkins-bot:
[mediawiki/core@master] Disable wgLegacyJavaScriptGlobals by default

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

Can we also enable this on meta.wikimedia.org given it can contain global JS ?
What is the plan and the blockers for rolling this out further?

Krinkle added a comment.EditedAug 12 2020, 2:53 AM

Can we also enable this on meta.wikimedia.org given it can contain global JS ?

The config applies to when/where the script executes, not where it is stored. Can you elaborate on why you'd like to do Meta-Wiki next?

What is the plan and the blockers for rolling this out further?

Lower numbers at https://grafana.wikimedia.org/d/000000037/mw-js-deprecate?panelId=7&fullscreen. Note that those numbers are 1/100 of the actual numbers, and also doesn't count anons.

The config applies to when/where the script executes, not where it is stored. Can you elaborate on why you'd like to do Meta-Wiki next?

If a user is using global JS on meta wiki they have a chance of seeing the client side error when they next edit and realize it doesn't work before it appears on mediawiki.org =.

Lower numbers

Yes but what kind of outreach (e.g. user notice) has been done and is planned to get lower numbers?

Has it been considered using mw.notify to notify users of these problems e.g. "There is a problem with one of the gadgets you have installed. This error will continue to show until the associated gadgets have been removed or updated." ?

Given production code is not using these globals I think it's fair to use mw.notify in this way and makes the error visible to the users using them and the maintainers.

I'm particularly concerned with these errors going unfixed as now that I'm reviewing logstash for client side errors, on many occasions I've been able to identify users and the pages they are visiting through the pages they edit.

Jdlrobson added a comment.EditedThu, Sep 10, 3:21 PM

@Krinkle any objections to enabling this on meta wiki? After enabling client error logging on meta wikipedia I've managed to squash a huge bug that was impacting lots of people loading the script in foreign wikis via global scripts by observing a single occurrance of an error there that happened on meta wiki. I truly believe having it enabled on meta wiki, where global scripts are managed will help with upgrading this code.

Using mw.notify has been considered in the past. It is used on some wikis already for users in the interface-admin or sysop group. Beyond that, I don't think it's something we should use for end-users as for the most part these errors are inconsequential to them (whatever is broken isn't something they want, need, or know about), and not in their realm to understand or know how to do anything about.

Using Meta-Wiki as the next step seems fine. I do think it would be fairly disruptive though, and I'm not sure about most global scrips being maintained there. That's not been in my experience anyway. User's personal global.js is there of course, but I generally don't actually utilise the scripts there, and the config of meta-wiki doesn't apply to scripts imported at run-time from Meta-Wiki to local wikis, where the errors are generally seen.

Want to write the blurb for the next Tech-News?

We have client side error logging on meta wikipedia now, so I'm happy to jump in and fix the most prominent errors and/or generate a list of scripts that are still active and broken.

Ahecht added a comment.EditedThu, Sep 10, 4:21 PM

Beyond that, I don't think it's something we should use for end-users as for the most part these errors are inconsequential to them (whatever is broken isn't something they want, need, or know about), and not in their realm to understand or know how to do anything about.

A quick search on the English Wikipedia for deprecated globals shows that they're being used on about 5,000 js pages, most of which are in the userspaces of editors that are not admins or iadmins: link.

Almost half of those are used directly in users' common.js, vector.js, or monobook.js: link

Can TourBot be used to fix uses? As an interface admin on meta I'd be willing to help replace the uses if I understand how to use tourbot