Jump to content

Topic on Extension talk:Gadgets

Activation state when adding/removing "default" on hidden gadget

4
Od1n (talkcontribs)

Suppose we have an hidden gadget that is – and always has been – hidden:

Foobar [ResourceLoader|hidden] | Foobar.js

If later we add the "default" keyword to it, will it become enabled for all users? Conversely, if later we remove the "default" keyword, will it become disabled for all users?

To put it otherwise, will the gadget be enabled/disabled for all users according to the presence or absence of the "default" keyword? Or is there any possibility that the activation state remains at what it was at a previous time (for instance, at the time the definition was created)?

I guess the activation state will match the presence or absence of the "default" keyword. But I would need to be 100% sure about this, as I considered tweaking a module that brings core functionality on frwiki, and it would rely on this behavior.

(for the sake of completeness, I know users can enable/disable gadgets – probably even the hidden ones – using the API instead of the Preferences page, but let's assume no one did this) (edit: apparently, according to phab:T299071, making such API request on an hidden gadget doesn't change its activation state)

PerfektesChaos (talkcontribs)

Every time a page is requested from the server, it is checked for this particular account for this particular action which gadgets will be sent for loading.

That means that a change in gadget definitions has full effect rather immediately.

Od1n (talkcontribs)

I had a quick look at the code, and phab:T299071 might be of great interest.

  1. Hidden gadget are not added to the mw.user.options data: Hooks.php#149.
  2. Later, the value is looked for, and because it doesn't exist, "onByDefault" is used as a fallback value: Gadget.php#249.

Therefore, we are sure hidden gadgets will be enabled/disabled depending on whether the "default" keyword is currently in the gadget definition.

Though, T299071 was only purposed as an optimization to reduce data size. I don't know if the loading behavior of hidden gadgets would have been the same without T299071. (edit: according to OP in T299071, hidden gadgets were already following this loading behavior before T299071)

PerfektesChaos (talkcontribs)

In the mw.user.options a copy of Special:Preferences of registered accounts is transferred to the page JavaScript environment. Actually these are the items where by default or at least by user tic an activated value says that this gadget is to be run.

If you declare a non-hidden gadget to be hidden later, I guess a shadow of the old (last in effect) state might survive in the mw.user.options object of registered accounts.

On page loading, the mw.user.options (which are empty for anonymous users) will set to some kind of true value for all default gadgets, if not opt-out by registered accounts.

There can be arbitrary entries in mw.user.options created to some extent, which were never part of Special:Preferences.

Independent of JavaScript and mw.user.options packages of modules will be provided and sent based upon the current account for this particular action rendered in this particular skin for this particular namespace perhaps matching a certain category.

Reply to "Activation state when adding/removing "default" on hidden gadget"