Unsure if this is ZeroBanner or ZeroPortal territory to associate the corresponding projects to this task - leaving this to the Zero team.

This is not a mobile bug. It should be done in core if anywhere.

Whoever in core or some WMF extension central to core would be implementing this, please feel free to reach out to me on this if you need a hand on our approach used for Wikipedia Zero.

In essence, in Wikipedia Zero land, we have non-ResourceLoader <script> tag making a request against the server, which in turn contains a <noscript> tag that would request an <img> for any <noscript> browsers. As both the server-side provided response for the <script> tag and the <img> tag have the same cache lifetime, we're able to infer basic JavaScript support versus <noscript> support, and then when we couple that with the known "blacklisted" UAs (jQuery incapable) that we're calling "ResourceLoader-incapable" ("RLI"), we can make a call on whether something is <noscript>, basic, or RL capable. Here's an email thread that helps to understand the derivation of the stats on Wikipedia Zero and the general mobile web Wikipedia experience:

https://lists.wikimedia.org/pipermail/mobile-l/2014-November/008315.html

And here's the segment of code in Wikipedia Zero land that emits the JavaScript or GIF banner: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FZeroBanner.git/ba1591e1d93f2adcca9195b40c24ae430ef493ff/includes%2FZeroSpecialPage.php

Remember, Wikipedia Zero code is only in force for users on Wikipedia Zero partner networks.

I was talking to @Halfak about sampling frequency and the working plan is that we'd want all of the logged metrics in FINCH to sample at a rate relative to the wiki size. @Milimetric was recommended as the best person to talk to about making sure that we stay within the acceptable limits for EventLogging, especially since some of the FINCH events could generate a lot of events, e.g. T75798: Capture session length of users and T75693: Capture browser size and screen size for web users

@Nuria @Milimetric Is that something, that Analytics have had on its radar yet?

@Volker_E: not yet. If a specific team would like to look into this, they should use Event Logging and we can help with that. If nobody has resources to do this but it's very important, we can play a bigger role, and you can just tag Analytics and we'll triage.

@Volker_E : analytics team does not do any instrumentation code of mediawiki, that corresponds to mediawiki developers and teams. If you need help with the strategy to gather this data via Eventlogging we can help you with that. Now, this ticket is quite old and the new browser data reports have a lot of info regarding browsers like opera mini w/o proper javascript support: https://browser-reports-test.wmflabs.org/#mobile-site-by-browser

@Volker_E I'm curious to your motivation to get this. I know the discovery team recently did some experiments around finding an answer to this as well, but I wasn't confident about the methodology they used to trust the data.

IMO if you are building software correctly, using progressive enhancement, you shouldn't need to care about whether a device has JavaScript enabled or not.

It's also worth noting that given we use ResourceLoader to treat many browsers as non-JS, simply tracking non-JS users is not useful.

(the original task is also not clear on the motivation here)

In T1384#2203722, @Jdlrobson wrote:

It's also worth noting that given we use ResourceLoader to treat many browsers as non-JS, simply tracking non-JS users is not useful.

It is important to know how many people are using old browsers (those we don't serve JS to although they do run JS), but that data is already available.

This would basically check what proportion of requests execute a <noscript> (see suggestion in description).

I agree this is not that high priority. I would guess the vast majority of people have JS running (so the only question is whether we serve JS to their browser).

• Talk:Compatibility#Who doesn't use JavaScript and Why? Now at https://www.mediawiki.org/wiki/No-JavaScript_notes

I put everything I could find a couple of years ago, in there. I still hope it can be converted into a proper documentation section/page, once we find up-to-date stats.
Possibly some of the details therein, will help in the meantime.

Is anyone still interested in this?

I believe it would be very useful to get more accurate statistics on our non-JavaScript users (both readers and editors if separable), for the purposes of product planning and task prioritization and generally for understanding our users.
The notes we've compiled at https://www.mediawiki.org/wiki/No-JavaScript_notes have very unclear/inconclusive #Metrics and nothing new for the last few years.
I don't know whether this task is the best place to request that, or if somewhere else should be used.

@Quiddity the mediawiki page you listed predates the browser stats: https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-os with those and our support matrix is actually easy to figure out the percentage of requests w/o javascript support (example: IE9 supports some js but we do not serve js to such an old browser). This applies to both users and editors so at this time, we have quite a lot of data to triage bugs based on browser usage. On my opinion this task can be closed.

@Nuria thanks for the reminder of that! I've added it to the page. (Docs or it didn't happen! ;-)
That helps us see some of the information, but it leaves out, e.g. users with no-JS extensions enabled, or users behind a corporate intranet that blocks JS, or users who had their page-load interrupted midway. I don't know how those wider circumstances are best technically captured, or if this is the right task to ask for it, or how much info we could get with minimal/feasible efforts? I'll leave it up to you though. :-) Also I've filed the related T213215: Improve Dashiki defaults for Browser selection.

Docs or it didn't happen! ;-)

Indeed. Super thanks

That helps us see some of the information, but it leaves out, e.g. users with no-JS extensions enabled, or users behind a corporate intranet that blocks JS, or users who had their page-load interrupted midway.

All those are fringe (and somewhat dated) cases that I doubt warrant specific data gathering nor will they play a part on teams deciding on bug triage due to javascript support, our current browser stats (that are also available internally by project) are more than sufficient to asses basic support. Closing ticket.