I think A or C make the most sense. B seems problematic as the tabs not visible without scrolling horizontally will be less discoverable.

The JSMinplus validator does not even support ES6 ( T75714). Even when it does, it's unlikely it would be constantly updated to support the latest ES variant of the day.

I think validating on save and saving the result as a page property is a pretty good approach.

I disabled the check for ProcseeBot's activity.

Now that ResourceLoaderModule::getSkins() patch has merged, possible approaches to move forward with this:

@Ankur0710 Please review https://www.mediawiki.org/wiki/New_Developers#Some_general_communication_tips and https://www.gerv.net/hacking/how-to-ask-good-questions/. In short, to get further guidance you should mention what you've tried so far and where exactly you're stuck.

Have we thought about coupling parse requests with the action=stashedit requests? The latter is also "real-time" with a debounce of 3 seconds IIRC. Instead of sending the full wikitext twice, how about creating a single API endpoint that does parse + stashedit? Or maybe modify either of those APIs to add an option to also do the other operation?

@Novem_Linguae What timezone have you set in Special:Preferences?

See also: T263931: Special:ActiveUsers misses some active users on some(?) wikis, T261290: Number of active users from ApiQueryAllUsers grossly different from Special:Statistics page

Couldn't SaveUserOptionsHook be used instead, as that's abortable?

In T241524#7733969, @Ciencia_Al_Poder wrote:

This also serves the purpose of tracking which pages will be using the gadget.

Do you perhaps have wgResourceLoaderValidateJS set to false?

In T241524#7673707, @Izno wrote:

That said, I remain in the position that on-click interaction with supportsUrlLoad already fits 95% of the use cases ...

Preferences of enabled user gadgets are public. This helps with caching of the gadget startup module (group=user which enables them to be cached, unlike group=private which adds them to the HTML on every page load). I think this is fine regardless of the caching benefit as it mirrors the public nature of personal common.js pages, enabling technical editors to help others and identify use of malicious scripts.

After doing some more extensive research, I figured out a better approach (see linked patch, ready for review) that does not involve embedding modules on the page. This approach enables user gadgets to exist as normal modules, triggered by a user-level startup module. The issues with the earlier approaches are resolved, and only trivial resourceloader changes are needed. Contrary to bullet 5 in T36958#7594392, user gadgets can be loaded adhoc via load.php?modules=ext.usergadget.p12345 (where the number is the pageid of the definition page) though this would not be considered officially supported.

@Nux This task is essentially about T36958#387742, though I believe setting position is no longer an explicit RL feature (any module with just styles load without flicker).

@Ammarpad I forgot that sitenotices on enwiki were dismissable. In testing on my localhost wiki, they were persistent – as MW core doesn't have a dismiss capability. Which is the extension that makes them dismissable? I think the usecases are for persistent namespace notices, so maybe we could change the extension to not work on ns notices.

A hacky alternative to provide ES6 support in gadgets would be:

• Introduce a new reserved group which disables validation.
• Gadgets which mark themselves as es6-only are put in that group - so they are retrieved in a separate request than other gadgets and core/extension-loaded JS.

This means that if any one of these ES6-only gadgets contains a syntax error, all other enabled ES6-only gadgets would also fail, but core/extension-loaded modules and non-ES6 gadgets would work as usual. That seems like a reasonable compromise. Thoughts?

Thanks @Krinkle for investigating this.

However, the odd thing is that it works correctly on my localhost wiki (running on git master). But not on testwiki or even on beta cluster.

In webpack.config.js file, uncomment the line terserOptions: { output: { ascii_only: true } } for a unicode-free build. This adds 4kb to the size, but it now works fine as a gadget.

What is the usecase for specifying action=submit? If you're trying to target just the preview screens, note that if users have Live preview enabled, the previews are also displayed on the action=edit page. It's better to specify edit which loads the gadget on both edit and submit actions.

So far I've been able to get user gadgets to work with group=user and group=private, but with two major limitations:

1. Dependencies don't load. It appears that both group=user and group=private embed modules in the page rather than link them, and both don't support dependencies (or just behave weirdly with them, see T299288)
2. If the docs are to be believed, in group=user caches aren't shared with other users – which is bad because a single user gadget is same for all users so caches should be shared. In group=private I think they aren't cached at all.

This seems like an enwiki-specific workaround since for a missing feature (changing default preferences based on registration date) in core, not sure if extensions/CodeMirror is the best place for this or if it should be implemented somewhere else

T6469: Provide per-namespace site notices would help with this.

Also if I change GadgetResourceLoaderModule's getGroup() to return 'user', now the gadgets do load and run but without their dependencies.

Along with linking scripts, styles and datas from the original patch, linking of messages, the category, peers and gadget dependencies have also been implemented in the revised patch.

Regarding the relationship with T6469 – that adds a namespace-specific sitenotice, which would be cached once per namespace view so is very performant. But the caching implies that we cannot use {{PAGENAME}} or other magic words whose value differ between pages in the namespace.

In T204201#7617036, @PerfektesChaos wrote:

In T204201#7616924, @SD0001 wrote:

BTW, you will need two URL calls, one for JavaScript and one for CSS.

No, unless you use &only=scripts or &only=styles filters, the same call includes JS, CSS and JSON (and messages).

Well, I am to retrieve for appropriate content model:

• mw.loader.load( URL&only=scripts" );
• mw.loader.load( URL&only=styles", "text/css" );

Can't we use the LocalUserCreated hook to enable the feature for new users going forward? DiscussionTools uses this for enabling email notifications (for new messages in subscribed sections) for new users. This would require adding a config option so that only interested projects enable it, so re-adding the project tag.

Re-opening as I could try to file a patch and there are strong use cases for it – on enwiki there have been multiple discussions about showing a banner on top of draft pages. See latest discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#Universal_notice_for_draftspace

And please correct me if I am wrong, but from my experience load.php?modules= does not include or request dependencies nor messages

This is, unfortunately, wishful thinking. I have been reviewing gadgets on enwiki over the last few weeks, and have found XSS vulnerabilities in two of them.

While it's obviously not risk-free, I don't think it adds any more risk than what exists already with unmaintained and antiquated gadgets in wide usage. By default, I think gadgets should be treated as safe. It doesn't make sense to consider trustworthiness of gadgets when anyway they can be edited by just interface-admins. Many wikis are already using withJS and withCSS so for those sites nothing much changes (other than the delivery being RL-optimised). Communities where it's possible to get interface-admins to gadgetize vulnerable/malicious code likely have larger problems to worry about.

Tagging CommTech as steward of Preferences.

https://github.com/mck89/peast looks like the only php library available that can validate JS syntax with modes for different ES versions. However, the benchmarks are:

All things being considered, I think a parser function for loading gadgets would be a net positive, and better than having gadget definitions based on templates because (per the comments here and at T204201):

1. If the template is moved, the gadget loading behaviour should move with it
2. The gadget should also load on template sandboxes to facilitate development

This is also sometimes causing the API to emit status code 500, apart from internal_api_errors (which have status 200).

Gadgets can now be loaded with ?withgadget= URL parameter. This is live in production wikis.

Per T298010, the API is currently returning errors that look like this: internal_api_error_DBQueryError: [12099b97-17b0-42c5-883d-464328a6e662] Caught exception of type Wikimedia\Rdbms\DBQueryError I suggest a more informative error message be used in case of timeouts.

Yes

Adjusted description to focus on the problem, and also consider other approaches.

Yes I realised allowing files from multiple wikis in the same gadget could be complex. This is where the alternative/equivalent suggestion ("it should be possible to define a gadget which is entirely loaded from another wiki – essentially a "pointer" gadget") comes in – precisely based on what GlobalCssJs does. In terms of meeting the usecases, this is equivalent to the original suggestion as we can always create another gadget that uses it as dependency and adds the extra local files.

There is a one and only global name (but perhaps localized??) as page identifier and just one Gadgets-definition per user. Similar to Special:MyPage/Common.css which has a globally unique meaning. Well, better no localization but Special:MyPage/Gadgets-definition for all gadgets.

The usecases are same as that of global gadgets (T22153), but this is more moderate proposal, and could be more easily realisable. Apart from the technical complexity, truly global gadgets raise difficult questions – such as which community would maintain or edit the gadgets. In the absence of a sane code review workflow (T71445) and the very high access level (int-admin) required for editing, it will be difficult for users to maintain a gadget on a central foreign wiki.

1. User-script authors define modules in their userspace, with page title having a .gadget suffix. These pages get the GadgetDefinition content model. Definitions are in the same format as the existing Gadget definition namespace (with some changes like not having a "default" and "hidden" keys).
2. Users can save their list of enabled user modules (created by themselves or by others) via a titlesmultiselect field in gadgets tab of Special:Preferences.
3. ResourceLoader modules are dynamically registered based on the current user. For contexts like load.php where there is no concept of a "current user", no user gadgets are registered.
4. Dependencies and peers between user gadgets can be expressed using the titles of the definition pages (instead of the usual RL module ids).
5. The above setup means that a user gadget is loaded only if you enable it from Preferences or if it's a dependency/peer of another enabled user gadget. Adhoc loading via mw.loader.load/using is NOT possible (but of course the individual scripts/stylesheets can be loaded that way). edit: It would be possible, see T36958#7643239

The patch for T236603 adds a getSkins() methods to ResourceLoaderModule. If merged, skin modules can override it to provide the current skin name, solving this issue. This also gives skins the flexibility to allow certain modules to be exposed to other skins, if needed, such as for the usecase mentioned above (for use in a dependant skin).

If you were after a small overlay message which could say something like "Page has been edited in the meantime." or so, maybe that's an option.

Notes on testing the patch:

Bot frameworks generally build token caches to allow the user to write API calls like: api.post({ ...., token: tokenCache.get('csrf') }), so they don't have to fetch a token before each request. It's easier to refresh this cache in one request rather than go through the more complicated flow mentioned in OP.

So my idea may be more hacky than I'd realised and different from the purpose of skipFunction. I was expecting such a feature could be used by gadgets which are applications, not libraries. They wouldn't be depended on by other gadgets, either via gadgets-definition or by mw.loader.using(). So arguably the dependency management isn't important for them.

Convenient-Discussions has this feature – WIP comments are saved in localStorage, a feature I've found really useful not just because it saves them from browser crashes, but also because it reduces the tendency for impulsive comments and gives you the freedom of letting the comment sit, think things through, and come back to the page at a later date to finish the reply.

Can you explain it would have a significant performance overhead? The total data transfer for checking the latest revid of a page is https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&titles=Barack%20Obama&rvprop=ids, which is tiny. There are several other tasks for real-time update features in mediawiki, notably T34284.

Using JavaScript to query the latest revid of the page, say every 5 seconds, and checking if it matches the one client is seeing. To optimize this, the polling could be done only when that particular tab/window is active. Maybe it could be done using a web worker.

The "Publicly send thanks?" prompt is created using the jQuery.confirmable plugin which only supports two buttons. It doesn't look as if adding a third generalizes well for the plugin.

The ability is already available at the backend layer, both via the TemplateSandbox API as well as from normal webrequests. This can be invoked from scripts, eg. https://en.wikipedia.org/wiki/User:Jackmcbarn/advancedtemplatesandbox.js.