Change 885788 had a related patch set uploaded (by Jdlrobson; author: Kosta Harlan):

[mediawiki/core@master] Adjust default targets in RL/Module

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

Change 885903 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Gadgets@master] Gadgets should be enabled on mobile by default if not specified

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

@Jdlrobson Re: Tech News - What wording would you suggest as the content, and When should it be included?
For wording, I imagine something like this:

• In the "Future changes" section:
  • Gadgets and user scripts will be changing to load on desktop and mobile sites. Previously they would only load on the desktop site. It is recommended that wiki administrators audit the gadget definitions prior to this change, and add targets=desktop for any gadgets which should not load on mobile. [...MORE DETAILS & TRANSLATED-CONTENT-LINK?...]. [ 1 ]

I'm not sure if that is a clear and accurate summary, nor what else should be added (user-scripts?) or linked (ideally a translatable-page).
Please advise. Thanks.

P.s. I think there are 2 errors in the task-description?
(a) Should there be a | before the targets= in 2 of the examples?
(b) Should there be 1 or 2 (current) [[ at the start of all 3 examples?
But ideally all of this info would be on mw.o and translatable.

I'm not sure if that is a clear and accurate summary

That sounds good to me.

nor what else should be added (user-scripts?) or linked (ideally a translatable-page).

I think this Phabricator ticket should be clear enough for anyone who understands how that wiki page works.

P.s. I think there are 2 errors in the task-description?

fixed.

and add targets=desktop for any gadgets which should not load on mobile

Let's change this to

add skins= for any gadgets  which should not load on mobile

(ON second thoughts switching to skins is less disruptive on the long run)

What should be done with gadgets whose usability/usefulness really depends on desktop vs mobile, not on Vector vs Minerva (e.g. Navigation-Popups-Gadget, which doesn’t work without a mouse)? Should they explicitly be marked targets=desktop? Or how should we prevent mobile users from downloading them unnecessarily?

Listing all skins except Minerva creates a long list, makes it less obvious what’s excluded, and causes any eventual new skins not to get the feature, even if it was useful with that skin, which is the opposite of what we do with browsers (unless we know a browser is broken, we send JavaScript to it, assuming that it’ll work). I think it would be more maintainable if there was a new skins-except= gadget option.

NavPops is a hard question to me, I think, and worthy of thought regardless. Popups extension too, I wonder what that one does today for systems where the normal mode of use is touch. (Consider that if I really wanted, I could manage to use a mouse with a phone. SO has an interesting comment.)

Or how should we prevent mobile users from downloading them unnecessarily?

This is precisely the point for caching. It's a win for WMF at some slight mostly-one-time expense to everyone who uses the gadget, at least for this specific gadget.

Listing all skins except Minerva creates a long list, makes it less obvious what’s excluded, and causes any eventual new skins not to get the feature, even if it was useful with that skin

I think this is preferable anyway, as gadgets may not work with a skin or not be beautiful in that skin (witness the effort to get stuff to work with Timeless and Vector 22 and the general user dissatisfaction when they didn't), and adding a new skin to the gadget definition isn't difficult anyway, whereas defaulting to "not in that skin" makes everyone go "where is it" and not "ew bad skin".

I do agree that definitions get lengthy, but that feels more like it would be fixed in gadgets 2/3.0 with specific gadget configurations. Whenever that happens.

In T328610#8587808, @Tacsipacsi wrote:

What should be done with gadgets whose usability/usefulness really depends on desktop vs mobile, not on Vector vs Minerva (e.g. Navigation-Popups-Gadget, which doesn’t work without a mouse)?

I usually split those gadgets in 2: The one that can be enabled/disabled is a minimal script that does some checks (maybe if it's a mobile device, it's not a special page, etc) and then it loads the actual gadget that's defined as a hidden gadget. That's more flexible than defining the skin being used. However, it's a lot more burden since it involves splitting gadget source code and write code to load the gadget.

@Izno for page previews we do exactly this- load a minimal bit of code on mobile and desktop site which checks if touch events are enabled.
https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/resources/ext.popups/index.js#L3

In T328610#8587989, @Izno wrote:

Or how should we prevent mobile users from downloading them unnecessarily?

This is precisely the point for caching. It's a win for WMF at some slight mostly-one-time expense to everyone who uses the gadget, at least for this specific gadget.

How is not loading on mobile worse for caching than not loading for users who didn’t enable the gadget? I understand splitting caches on desktop vs mobile is bad if the ResourceLoader module would otherwise be loaded for everyone, but gadgets are loaded for a fraction of users anyway. (For example, NavPopups on enwiki is loaded by some 60 thousand users out of the 45 million registered users – while if we took only active users into account, the percentage would probably be higher, it’s still just a small part of the registered users, with zero anonymous users having the gadget enabled.)

Listing all skins except Minerva creates a long list, makes it less obvious what’s excluded, and causes any eventual new skins not to get the feature, even if it was useful with that skin

I think this is preferable anyway, as gadgets may not work with a skin or not be beautiful in that skin (witness the effort to get stuff to work with Timeless and Vector 22 and the general user dissatisfaction when they didn't),

Would users have been more satisfied if not some gadgets broke in random ways, but all gadgets didn’t load at all? I don’t think so. Yes, new skins can break things, but they don’t necessarily do so. (By the way, I use Timeless, yet I’m not dissatisfied when things break there as I understand that as a non-default skin, it gets a lower level of support. I would however be dissatisfied if things were simply disabled there in the fear that they may possibly have parts that don’t look perfectly. Because most parts of most things do just work.)

and adding a new skin to the gadget definition isn't difficult anyway

Provided there’s someone who adds it. On enwiki, this may not be an issue, but e.g. on huwiki there are only three interface admins, none of us being constantly available. Even a few hours can hurt if a very important gadget becomes unavailable due to a skin change, but the response time on huwiki can easily be days.

This seems unnecessarily disruptive. Gadget definitions need a way to target only mobile or desktop (they can't just use conditionals like code written in PHP or JS can). The ResourceLoader target system is going away (and per T303681: RL targets for gadget definition pages it hasn't really been working for gadgets anyway), so we need some kind of mechanism for setting the target in a gadget definition. Why not do that, make desktop the default, and then transition from the RL target system to that mechanism without requiring all gadgets in the world to be updated?

In T328610#8588245, @Tacsipacsi wrote:

How is not loading on mobile worse for caching than not loading for users who didn’t enable the gadget? I understand splitting caches on desktop vs mobile is bad if the ResourceLoader module would otherwise be loaded for everyone, but gadgets are loaded for a fraction of users anyway. (For example, NavPopups on enwiki is loaded by some 60 thousand users out of the 45 million registered users – while if we took only active users into account, the percentage would probably be higher, it’s still just a small part of the registered users, with zero anonymous users having the gadget enabled.)

There are default gadgets on multiple wikis that in fact load for everyone.

Would users have been more satisfied if not some gadgets broke in random ways, but all gadgets didn’t load at all? I don’t think so.

I do. When I think about this case, I think about whether it's easier for programmers to account for breakages before or after creating a new skin. Not having breakages means they don't have to account for it at all, except to field questions about why the gadget isn't in the skin yet. (I think about how some programming languages have exhaustive switch statements and some have implicit; if we change the program, one of those is much easier to account for.) I'm taking from my experience watching Timeless be slowly deployed that users have the expectation that a gadget will work perfectly in a skin as it's created. The one I particularly think about is HotCat and equivalent gadgets that manipulated the non-existent category field. The interactions those users had was "the skin is broken" rather than "the skin doesn't support things yet", and I think the second one would have been much more valuable and better for the users. MoreMenu was another that had no proper home. I'd rather have to opt gadgets in as they work, and leave them default invisible to view if they don't.

Yes, new skins can break things, but they don’t necessarily do so.

Vector 2022 was a mess on breaking things on stable Vector, and Timeless also did not get everything right. Minerva still doesn't support everything it really should.

yet I’m not dissatisfied when things break there

Neither am I for the same reason, but you and I are atypical. We're users sufficiently knowledgeable to be using Phabricator....

and adding a new skin to the gadget definition isn't difficult anyway

Provided there’s someone who adds it. On enwiki, this may not be an issue, but e.g. on huwiki there are only three interface admins, none of us being constantly available.

I think "not enough people to support new skins" is a social problem. Either make more interface admins or opt in to support from stewards and/or global interface editors. Separately, adding a new skin is a months long process. I'd be unpleasantly surprised if all three of you were absent for so long.

Even a few hours can hurt if a very important gadget becomes unavailable due to a skin change, but the response time on huwiki can easily be days.

That's exaggeration. And your case ("unavailable due to a") isn't improved or worsened by specifying skins in the gadget definition rather than targets. The only point where that's good or bad is when the skin is first added to begin with (or when the gadget is first added to the list of gadgets in the gadget definition), not if an unstable skin is changed. In that parenthetical case, you have to decide where it's loading anyway, so I do not see that as interesting. Hence the discussion about new skins.

In T328610#8590616, @Tgr wrote:

This seems unnecessarily disruptive.

I agree this change is disruptive, just as it has been to server-side code that has depended on the targets system. However, skins are much more future-safe than the current targets system is, so I do not agree with unnecessarily.

Gadget definitions need a way to target only mobile or desktop (they can't just use conditionals like code written in PHP or JS can).

That's precisely what Ciencia pointed to as a solution. Make a base hidden gadget with the primary content and make a short loader gadget that checks for whatever criteria it thinks it needs for the rest of the gadget to be successful and then load the base hidden gadget if it passes those checks.

The ResourceLoader target system is going away, so we need some kind of mechanism for setting the target in a gadget definition.

Yes, it's precisely because the RL target system is going away that the same API in the gadgets extension is going away.... One might argue that you could still keep the verbiage targets=desktop|mobile and then change RL such that mobile points to whatever skin is on mobile, but that assumes a mindset of one skin on mobile, rather than the many we might have that support the resolutions and form factors that mobile does (e.g. Timeless or Monobook on "desktop" website on mobile form factor).

Maybe something that would be valuable would be for RL or similar to have a standard way to detect "mobile" systems. The SO link I pointed to earlier indicates there are many ways that someone could attempt to identify mobile systems, and that person would be wrong. (Or maybe it's reasonable that each gadget author attempt to deal with touch screens as a basic "you're developing Javascript now, best you know a few things".) But this could be dealt with in mw.util or similar rather than in a gadget definition.

and per T303681: RL targets for gadget definition pages it hasn't really been working for gadgets anyway

That task is actually entirely irrelevant. We do not use Gadgets definition namespace pages (yet). It continues to be a feature of the future.

Why not do that, make desktop the default, and then transition from the RL target system to that mechanism

Desktop is the default today, it says that in the task description and in the code. But maybe I'm not understanding this line...?

without requiring all gadgets in the world to be updated?

They really should support all skins at this point or be deliberate about not supporting some skins. Minerva has been deployed for a decade now, Timeless for half that time, and now Vector 2022.

If a gadget doesn't support Minerva, we probably already know it. I'd venture Minerva as the most common case of non-support as being the mobile skin that only the few use on desktop due to its not providing all the functions the rest of the skins do, which is where I would expect most people to have opted in to a gadget. There might be a valid point that some of the gadgets that don't work "in mobile" would work in Minerva and simply aren't loaded on mobile (NavPops is a good example), but those really should be updated anyway to make the correct check(s); I'd consider it a bug otherwise.

In T328610#8595149, @Izno wrote:

There are default gadgets on multiple wikis that in fact load for everyone.

Yes, there are default gadgets. A few. Most gadgets aren’t default, so it can be planned for non-default gadgets.

Not having breakages

Gadgets not loading is a breakage. Call it technically however you want, it’s breakage in that it breaks workflows. Instead of hoping things won’t break (or doing extensive testing to prevent breakage), it makes sure that things will break.

Yes, new skins can break things, but they don’t necessarily do so.

Vector 2022 was a mess on breaking things on stable Vector, and Timeless also did not get everything right. Minerva still doesn't support everything it really should.

I mean not all gadgets broke (probably most didn’t break). If Vector 2022 support was opt-in, all gadgets would have been disabled, including those that work perfectly fine.

Neither am I for the same reason, but you and I are atypical. We're users sufficiently knowledgeable to be using Phabricator....

Users not knowledgeable enough to use Phabricator will probably report issues on local village pumps – which are exactly the places to reach local gadget maintainers.

In T328610#8590616, @Tgr wrote:

This seems unnecessarily disruptive. […] Why not do that, make desktop the default, and then transition from the RL target system to that mechanism without requiring all gadgets in the world to be updated?

Because unless the default becomes desktop+mobile, many gadgets will be unnecessarily disabled on mobile due to gadget maintainers not adding the extra option. It’s actually the same thing why I’m advocating for the skins-except= option – the default should be that things just work across skins and devices, and they should have to be explicitly disabled if they don’t (which is also a signal that there’s room for improvement).

In T328610#8595588, @Tacsipacsi wrote:

Call it technically however you want, it’s breakage in that it breaks workflows.

Yes, the skin potentially doesn't support gadget X that user Y expects to work. I would rather, as I have now said multiple times, affirmatively add a statement that says "this gadget works in this skin", along with the assessment that would likely be done for all gadgets at the same time, and tell the users "yes, gadgets aren't assumed to work in a new skin", than have the converse discussion "the gadget doesn't work for this skin", "yes, that's because the gadget is broken".

Instead of hoping things won’t break (or doing extensive testing to prevent breakage), it makes sure that things will break.

No, it keeps users safe from the bad assumption that their gadget will work in arbitrary new skin. Or that their gadget won't emit nasal demons on screen because the gadget was not explicitly designed for a new skin.

Users not knowledgeable enough to use Phabricator will probably report issues on local village pumps – which are exactly the places to reach local gadget maintainers.

Which isn't relevant to the point you were trying to make. You made a statement that you, ad hominem, didn't expect things to work in X skin because you understand that not everything will work in new skins. That's not how standard users are, at VPT/equivalent or elsewhere.

But, I do not think you and I will agree at this point, so I will leave this one to others. It's probably six of one, half-dozen of the other. Your request does require new effort and a similar API that should probably result in deprecating the old API, so that's up to a PM or component maintainer to decide if you are asking WMF to add support for the new option.

In T328610#8595149, @Izno wrote:

Make a base hidden gadget with the primary content and make a short loader gadget that checks for whatever criteria it thinks it needs for the rest of the gadget to be successful and then load the base hidden gadget if it passes those checks.

That's bad even for a joke. You'd have to double the number of gadgets (which is a performance concern due to startup module size), ship a bunch of pointless code to all readers, it would block the loading of the actual gadget until the loader gadgets executes on DOM ready, it wouldn't work for style-only gadgets etc.

One might argue that you could still keep the verbiage targets=desktop|mobile and then change RL such that mobile points to whatever skin is on mobile

That is in fact what I'm arguing for (except the change would have to be in Gadgets, not ResourceLoader). The Wikimedia codebase already heavily relies on mobile checks to limit payload size for mobile devices; whether that check is based on skin or domain or user agent or whatever is an implementation detail that gadget maintainers should not be forced to reimplement.

and per T303681: RL targets for gadget definition pages it hasn't really been working for gadgets anyway

That task is actually entirely irrelevant. We do not use Gadgets definition namespace pages (yet). It continues to be a feature of the future.

Right, thanks, I misunterstood that.

Desktop is the default today, it says that in the task description and in the code. But maybe I'm not understanding this line...?

Desktop is the default today, the patch attached to this task would change it to desktop+mobile. Changing defaults is disruptive; we should make Gadgets declare modules with a mobile+desktop ResourceLoader target property but only adding them when on the specified target. That fixes the ResourceLoader cache splitting problem and unblocks the way for doing away with targets in ResourceLoader entirely, while allowing gadget authors to determine what does and doesn't make sense for mobile, and without creating a zillion misbehaving / broken gadgets. (There would be some change in how dependencies behave as a desktop+mobile gadget depending on or mw.loader.load-ing a desktop-only gadget while being on mobile would work (now it results in an error), but I don't think that's a big deal.

They really should support all skins at this point or be deliberate about not supporting some skins. Minerva has been deployed for a decade now, Timeless for half that time, and now Vector 2022.

The vast majority of gadgets only get attention when they break. Even the most popular ones like aren't always well-maintained, and the more niche ones are never touched or examined until they become a problem. Turning hundreds of gadgets into problems at the same time is... not a great idea.

In T328610#8596303, @Tgr wrote:

You'd have to double the number of gadgets (which is a performance concern due to startup module size), ship a bunch of pointless code to all readers, it would block the loading of the actual gadget until the loader gadgets executes on DOM ready, it wouldn't work for style-only gadgets etc.

Reasonable concerns. OTOH, right now the "bad" edge case is NavPops. I bet we can enumerate the problematic gadgets on one hand for gadgets that actually need something of this sort. Separately, the bad cases probably need these fixes regardless. As a particular example of an edge case, I believe NavPops doesn't check today for the general user ability to hover and should, so that's a check that needs to be added regardless of whether it's loading on mobile or desktop, because neither of those two targets do that today. And then this problem is solved for that gadget, since it shouldn't be judging mobile use based solely on the domain or skin it's on. As I suggested above, that's a check that probably could/should be added to mw.util or other library. I don't think it could be done in the definition, especially since I could go from tablet-without-mouse to tablet-with-mouse pretty easily (as a particular example).

Maybe there are other edge cases, but I doubt there are significant numbers of them for the "it doesn't fit into a skin-determined loading system" case being contemplated.

Regarding particularly the startup module size, even on a wiki with say a hundred gadgets (en.wp is a bit north of that, 110ish), would only increase by some quantity in the realm of 2k on the top end, and probably much less. For users who already don't have content caching, that doesn't seem like a significant cost. YMMV I guess.

The Wikimedia codebase already heavily relies on mobile checks to limit payload size for mobile devices; whether that check is based on skin or domain or user agent or whatever is an implementation detail that gadget maintainers should not be forced to reimplement.

I don't think I disagree on this. However, right now mobile target indicates exclusively mobile domain, and that's bad. Changing that to mean "skin displayed on mobile" isn't all that great either, because that may/will change. Changing to skins today skips that issue.

One might argue that you could still keep the verbiage targets=desktop|mobile and then change RL such that mobile points to whatever skin is on mobile

That is in fact what I'm arguing for (except the change would have to be in Gadgets, not ResourceLoader).

Why not do that, make desktop the default, and then transition from the RL target system to that mechanism

Desktop is the default today, it says that in the task description and in the code. But maybe I'm not understanding this line...?

Desktop is the default today, the patch attached to this task would change it to desktop+mobile. Changing defaults is disruptive; we should make Gadgets declare modules with a mobile+desktop ResourceLoader target property but only adding them when on the specified target. That fixes the ResourceLoader cache splitting problem and unblocks the way for doing away with targets in ResourceLoader entirely, while allowing gadget authors to determine what does and doesn't make sense for mobile, and without creating a zillion misbehaving / broken gadgets. (There would be some change in how dependencies behave as a desktop+mobile gadget depending on or mw.loader.load-ing a desktop-only gadget while being on mobile would work (now it results in an error), but I don't think that's a big deal.

Ok. Thanks for clarifying your proposal.

and without creating a zillion misbehaving / broken gadgets.
The vast majority of gadgets only get attention when they break. Even the most popular ones like aren't always well-maintained, and the more niche ones are never touched or examined until they become a problem. Turning hundreds of gadgets into problems at the same time is... not a great idea.

I think this is quite some hyperbole here. It's probably not in the 100s and certainly not zillions. Regardless, I think it can be fixed trivially by bot by updating the gadget descriptions to target skins, conservatively choosing not to load gadgets on Minerva if the gadget definition does not already include mobile. That's not much worse for people using Minerva on desktop (and can be trivially fixed with a "come here if this turned something off and we can flip it on" and/or "this needs to be fixed for mobile") and no worse than today for those gadgets that (don't) assume certain things about mobile.

@Tgr usually when people target desktop-only what they are really doing is avoiding supporting the Minerva skin. I see it as similar to browser user agent sniffing - we should be feature detecting rather than guessing. If the gadgets extension wants to reimplement the targets system it can, but I'd question the value of that. What kind of gadget are you imagining that wouldn't work on the mobile site that cannot be feature detected?

In the case of Navpopups it seems more helpful to always load it - as sometimes the user may be using the mobile domain on a desktop browser. It might not happen often but there's no reason that code can't work there.

Desktop is the default today, the patch attached to this task would change it to desktop+mobile.

Changing defaults is disruptive;

The default has already shifted on several occassions:

1. Previously we didn't load gadgets at all on mobile, and then we added to the option - that was a positive change in default.
2. We also recently changed common.js to run on Minerva, with little disruption.

Perhaps it's disruptive, but it is also beneficial. There are users using Minerva on desktop and users using Timeless on mobile devices and there gadgets are either loading or not loading. We often get complaints along the lines of "the mobile site is bad because X gadget doesn't work" and most of the time I find it's just because of targets.

and without creating a zillion misbehaving / broken gadgets.
The vast majority of gadgets only get attention when they break. Even the most popular ones like aren't always well-maintained, and the more niche ones are never touched or examined until they become a problem. Turning hundreds of gadgets into problems at the same time is... not a great idea.

As I state in the description I'll be monitoring logstash, so at most we're looking at disruption over a short period of a day that most users won't notice. If there are no JS errors this means the gadget is working correctly as expected. Where JS errors occur they will only do so because of unmet expectations on the DOM which will be easy to fix. A few visual tweaks may be needed, but we're already doing those for Vector 2022 so now seems like a great time to make the switch. I'm also not scared of going in and fixing actively used gadgets where necessary. Zillions of gadgets will certainly not break. In fact much of the leg work was already done when we enabled common.js on mobile as many users were loading popular gadgets through there.

In T328610#8599653, @Jdlrobson wrote:

If there are no JS errors this means the gadget is working correctly as expected.

This is just not true. If there are no JS errors, that means that the gadget causes no log spam. Nothing more. For example, many gadgets use jQuery to query the DOM – jQuery doesn’t cause errors if the requested DOM element doesn’t exist, it just turns into no-op mode. Operating in no-op mode is in most cases definitely not “working correctly as expected”, even though it causes no JS errors (except for certain special cases, like trying to get the DOM element from the jQuery object).

@Tacsipacsi right. .. but that's already an issue on the skin already e.g. Minerva can be used on the desktop site via Special:Preferences and the code loads there. This doesn't change that it just brings more visibility to the problem which hopefully will lead to the gadget being fixed. I'm not sure exactly what you mean about NOOP mode and why that's a problem. My understanding was there was concern around disruption and I'm struggling to see the disruption running code that doesn't do anything has on end users?

My understanding is this represents a change effectively in the Gadgets extension, with added outreach by Reading Web team in relation to that change. I don't see a change or question here relating to RL, untagging as such.

In T328610#8611563, @Jdlrobson wrote:

I'm not sure exactly what you mean about NOOP mode

Let’s take an example. #p-search exists in all WMF-deployed desktop skins (i.e. Vector-2010, Vector-2022, Monobook, Timeless, Modern and Cologne Blue). As long as we don’t care about Minerva (to be honest, I don’t really care about Minerva-on-desktop – although, of course, I do care about Minerva-on-mobile), the following code works as expected (the result doesn’t necessarily look nice, but it’s usable):

$('#p-search').append('<input type="button" value="Foo">')

If the same code runs on Minerva, nothing happens. Neither does it do anything (it can’t append the button to #p-search, it doesn’t exist in Minerva), nor does it throw an error; it doesn’t even log a warning.

and why that's a problem.

I didn’t say it’s a problem, I only said that it’s not “working as expected”. I think even some disruption is acceptable to achieve the goal of supporting mobile being the standard.

My understanding was there was concern around disruption and I'm struggling to see the disruption running code that doesn't do anything has on end users?

Actually it can cause disruption, namely when only parts of the gadget operate in no-op mode. In worst case, it can remove things from the DOM (or hide them), and try to add the replacement somewhere else, the removal working, but the replacement not, making the given functionality inaccessible.

I think this is clear about the change impacting GADGETS, and that they will start loading on mobile unless tagets= is used, and mobile is NOT in there.

However, how is this change impacting "user scripts"? What exactly is changing there? (e.g. user:xxx/common.js behavior)??

User common.js already loads on mobile so no change there.

So as far as this task being about "...and user scripts to run on mobile", should everything about "user scripts" be removed from the title/description/tech news notifications?

@Tacsipacsi Theres no reason why that p-search code should not work in Minerva. The fact the ID isn't present is a result of a lack of a stable API [1]. I'm hoping this change presents a mindshift away from "gadgets don't work in mobile" to "why doesn't this gadget work in mobile, how can we improve the code?".

On a related note, there was some confusion on one of the wikis suggesting the default is confusing and should be changed ( https://www.mediawiki.org/w/index.php?title=Topic:Xao0504zarqz8k5b&topic_showPostId=xet4aschsc6fzwne&fromnotif=1#flow-post-xet4aschsc6fzwne )

[Note 1] Even though we use it as if it is, a CSS selector is not a stable API unless the presence of that ID is enforced by the software and if we want to consider it to be our code should make it impossible for a skin not to output it. Ideally we'd have something like mw.util.getSearchFormElement() to abstract this away.

Change 885903 abandoned by Jdlrobson:

[mediawiki/extensions/Gadgets@master] Gadgets should be enabled on mobile by default if not specified

Reason:

Leaving decision on whether to do this or not to gadget authors. I am not considering this a blocker for removing the targets system from MediaWiki core.

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

Added context to my abandoned patch and removal of parent task above so it's clear:

• I'm not considering this a blocker to T127268.
• If there is no action here, and T127268 is done, it will mean gadgets are automatically loaded on mobile
• If maintainers feel there is value in retaining some sort of targets system for mobile that is not met by the existing skin field, they should feel free to implement that. While I'm not considering that a blocker, I think delaying the removal of targets from core is reasonable.

Change 931956 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Gadgets@master] It should not be possible to set targets

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

Okay given all the discussion and lots of reflection, I'm okay to compromise here and continue to support targets for gadgets on a temporary basis. I'll have a patch for that by the end of the week (maybe today). This won't use the ResourceLoader targets system directly and will be compatible with existing gadgets.

I do think on the long term we should replace targets in gadgets for a more sophisticated system. I like the idea from @Tgr for using skip functions - that seems more in line with what we actually want here. These skip functions could potentially be predefined so you might have a gadget that requires support for touch devices (ReferenceTooltips might benefit from that for example) that could mark itself up like so:

gadget.name[ResourceLoader|default|skipIf=TOUCH_DEVICE]

The concern around performance is noted - so far I'm not seeing major problems with this change as most is not render blocking - but there are certainly some wikis which have gadget performance problems on desktop AND soon mobile, so this change is also highlighting the need for gadgets to be more responsible about performance and possibly impose some kind of budget - it.wikisource.org for example seems to load 500kb of gadgets for anonymous users if I'm reading things correctly.

In T328610#8974807, @Jdlrobson wrote:

Okay given all the discussion and lots of reflection, I'm okay to compromise here and continue to support targets for gadgets on a temporary basis. I'll have a patch for that by the end of the week (maybe today). This won't use the ResourceLoader targets system directly and will be compatible with existing gadgets.

Thank you! To avoid surprising gadget maintainers once again, please state an approximate timeline now. For example, a natural choice would be removing this temporary support either in the last WMF branch of MW 1.41 (to avoid having to maintain it in a release version) or the first WMF branch of MW 1.42 (to have third-party users also benefit from it in 1.41). The last 1.41 branch is expected in mid-September, that’s probably enough time to migrate everything if gadget maintainers know the deadline in advance.

Also, to make it clear: you backed out from the deprecation warning, but not from changing the default, so gadgets not specifying targets still start to load on mobile when the train reaches the given wiki, right?

I do think on the long term we should replace targets in gadgets for a more sophisticated system. I like the idea from @Tgr for using skip functions - that seems more in line with what we actually want here. These skip functions could potentially be predefined so you might have a gadget that requires support for touch devices (ReferenceTooltips might benefit from that for example) that could mark itself up like so:

gadget.name[ResourceLoader|default|skipIf=TOUCH_DEVICE]

Predefined functions are not much more expressive than the current system. What about allowing to specify a Lua script that would receive some data and return a boolean indicating whether to load the gadget? For example, a log/history filter gadget may want to get loaded on Special:Log and action=history, an edittool gadget on action=edit and Special:Upload, an AfD helper gadget on subpages of Wikipedia:Articles for deletion, a one-click user right request closer gadget should load on the bureaucrats’ noticeboard if the current user is a bureaucrat and on admins’ rights requests board if the current user is an admin etc. (It could be any other scripting language as well, but Lua is what’s already in production.)

In T328610#8974807, @Jdlrobson wrote:

I do think on the long term we should replace targets in gadgets for a more sophisticated system. I like the idea from @Tgr for using skip functions - that seems more in line with what we actually want here. These skip functions could potentially be predefined so you might have a gadget that requires support for touch devices (ReferenceTooltips might benefit from that for example) that could mark itself up like so:

gadget.name[ResourceLoader|default|skipIf=TOUCH_DEVICE]

Sounds interesting in general. Problem with skipIf=TOUCH_DEVICE is that not all devices are touch-only (a single laptop can have a touch screen, trackpad and a mouse). Things like NavPop should probably have addIf=HOVER_DEVICE.

In any case skipIf/addIf sounds like a nice idea. Maybe skipIf=device.hover, addIf=skin.minerva. If definitions would be changed to JSON-lines I would be even happier 😉. The longer those get the harder it is to read them. Syntax highlighting in future would be nice too.

Edit: Never mind the JSON part. I forgot that's already part of Gadgets 2.0 that got staled.

Change 934005 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/Gadgets@master] Gadget maintains its own version of targets system

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

Change 931956 abandoned by Jdlrobson:

[mediawiki/extensions/Gadgets@master] It should not be possible to set targets

Reason:

Please see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/934005

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

Does that mean gadgets will still be available for all skins by default? So this would be a default gadget for all skins and targets?

wikiflex [ResourceLoader | hidden | default] | wikiflex.css

And the latest change is that this would still work at the moment?

mobile.only [ResourceLoader | hidden | targets=mobile | default] | wikiflex.css
desktopskins.only [ResourceLoader | hidden | targets=desktop | default] | wikiflex.css

As a side note, although I agree with the change for mobile to be default, there are some problems at the moment with it. Like for example after this rollout I noticed that adding tabs is not working T340728. On the other hand Popups is working fine on pl.m.wikisource now which is kind of crazy 🙂 (obviously not working with touch devices).

Skins and targets are different concepts. Skins are Vector, Minerva Neue etc., targets are desktop and mobile. The target depends on whether the domain name includes m., and controls a few things: on mobile, in addition to using the Minerva Neue skin by default, there are a few mobile-optimized special pages like Special:MobileDiff, a different editor is used etc. Usually, Minerva Neue is used with target=mobile and other skins are used with target=desktop, but one can use Minerva on desktop (skin=minerva, target=desktop) or, say, Timeless on mobile (skin=timeless, target=mobile). The default has always been, and will continue to be, to load on all skins, provided that other requirements are met.

Handling of targets changes. The default used to be targets=desktop, which now changes to targets=desktop,mobile (58463ce, this does roll out this week if I understand @Jdlrobson’s intentions correctly). One can still override targets, this doesn’t change this week: if you set targets=desktop, the gadget is unavailable on mobile – it’s not loaded automatically, and ResourceLoader refuses to load it using mw.loader.load('ext.gadget.*') on mobile.

Change 934005 introduces yet another variant: if targets=desktop is set for a gadget, it will still not be loaded on mobile even if the user enabled it or it’s default, but manually loading using mw.loader.load('ext.gadget.*') will work on all platforms, regardless of the targets setting. Code using mw.loader.load to load a gadget should make sure on its own that it’s appropriate to load the given gadget.

(Just to make it clear: I used targets=desktop throughout the examples above, because it’s way more common, but targets=mobile also works symmetrically in all stages – except of course that the default before 58463ce was asymmetrically targets=desktop.)

For Tech News - Please let me know when an entry is needed and what it should say (or add it directly). I can semi-understand what you're talking about above (thanks for the detailed description Tacsipacsi!), but I'm not at all sure how to best summarize it in 2-3 sentences, and I'm not sure if anything needs to be included this week (deadline ~12 hours from now). Thanks!

After a quick discussion, this is now added to https://meta.wikimedia.org/wiki/Tech/News/2023/27 - It will be frozen for final translations in ~12 hours, in case any edits are needed before then. Thanks again!

Change 934005 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@master] Gadget maintains its own version of targets system

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

In T328610#8974825, @Tacsipacsi wrote:

What about allowing to specify a Lua script that would receive some data and return a boolean indicating whether to load the gadget?

That's pretty much what a skip function is, except it's JS, not Lua (since it needs to be run in the browser, not during page parse).

Something you can use for things like popups:

// popups
// only on devices that can hover (not on touch-only)
if (!window.matchMedia("(hover: none)").matches) {
	importStylesheet('MediaWiki:Gadget-navpop.css');
	mw.loader.using( "mediawiki.api,mediawiki.user,mediawiki.util,user.options,mediawiki.jqueryMsg".split(',') , function() {
		importScript('MediaWiki:Gadget-popups.js');
	});
}

So far, it seems to behave well (doesn't load on smartphones, but loads on touch-screen laptops). It has quite good support:
https://caniuse.com/mdn-css_at-rules_media_hover
https://caniuse.com/matchmedia

An example with a loader pattern:
https://pl.wikipedia.org/wiki/Specjalna:Gad%C5%BCety#gadget-Navigation_popups

@Jdlrobson is it possible work on this task caused the issue in T341421 ? The advice here to set all skins except Minerva is actually causing problems.