Yes, the fix has already been deployed and confirmed to work.

@Dvorapa: Yes, this was fixed some time ago.

It would be in wmf.8; the assumption I made in T237709#5680065 that wmf.8 was going to be skipped in favor of wmf.9 seems to not have been accurate. But wmf.8 hasn't made it past group 0 due to various issues (T233856). At this point I don't know whether wmf.8 will wind up being deployed at all or if we'll go straight to wmf.10.

In T237709#5721181, @Xaosflux wrote:

The "problem" is that "resolving" tickets doesn't mean resolving "incidents" or "problems".

I remember complaining about that 10 years ago. ;) That was back in the days when getting a fix deployed took months or years, rather than a week or two.

But from a "work tracking" perspective it does make sense: absent the issue somehow not being completely fixed after all, there's no more work to do specific to this task. The deployment that we're waiting for is a bulk deployment of all the changes since 1.35.0-wmf.5. With the way things are, if we left the task open until the deployment actually happens we'd probably actually wind up with no one remembering to actually close it. If we wanted to only close tasks post-deploy, we'd need some sort of "waiting for deployment" queue that someone (human or bot) would go through to make sure all the tasks actually get closed. Maybe that would be a good model to change to, but if so it should be proposed as its own task.

I note that this was intended to have a fix, but I'm still receiving the same error on the English Wikipedia.

So far as the question by @MMiller_WMF , I use the desktop version because:

This seems to have, if anything, gotten worse. Without thinking I clicked on them this morning (hey, I can't be responsible for what happens before I have my coffee :) ), and it entirely locked up Firefox, to the point no controls were responsive. I had to go in and force-stop and restart Firefox to get it back working.

I can confirm that I've had this issue as well.

Confirmed working. Thanks to @Plenz for taking a look at it so quickly!

@Aklapper: Plenz is listed as the tool maintainer, so he seemed like the right one. I presume that can be changed if need be?

In T195625#4254813, @Legoktm wrote:

In T195625#4252427, @Seraphimblade wrote:

It did work for me on Chrome on Android, but only apparently per session. Every time I'd open a new window (which I do frequently when, for example, reviewing discussions, doing speedy deletions, etc.), I would have to go hit that once again. When I'm talking about an opt-out, I'm not talking about something I'll have to do again and again, I'm talking about something I can set once.

Ack.

OK, so based on all of the provided feedback, we're going to lower the mobile breakpoint to something around 500px (T196213) so people mostly shouldn't see it on desktops, and I worked out how to add a user preference to fully opt out of responsiveness, and just get the classic desktop styles: https://gerrit.wikimedia.org/r/#/c/437150/. Will that take care of most peoples concerns right now?

In T195625#4252415, @Legoktm wrote:

In T195625#4252397, @Ahecht wrote:

If you want to opt-out, you can use your mobile browser's "Request desktop site" option

This is demonstrably false. For most mobile users, they cannot use their browser's "request desktop site" option, since it has been documented that this option does not increase the viewport beyond the magic 850px number in Chrome and Safari (which make up 70%-90% of mobile web users, according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers). In fact, the only browser that this has been documented to work on is Firefox, which makes up less than 1% of mobile web traffic.

I don't have an iDevice to test Safari on, but using the latest Chrome from the Google Play Store, it works for me:

Does it not work for you on Android Chrome? What device / Android version are you using?

In T195625#4250989, @Legoktm wrote:

In T195625#4250985, @Xaosflux wrote:

@ashley if I'm reading the logs correctly, this got implemented based on your approval (+2'd) <anyone please correct me if this is wrong>. Can you explain your reasoning for how this satisfied the normal requirements including the need to "socialize high impact changes within the development community"?

It was well socialized within the development community. wikitech-l was notified a month beforehand, in addition to a post on the English Wikipedia's technical village pump. After it was merged, I sent out an email to wikitech-ambassadors, and but missed the Tech News deadline by a few hours. Aside from Tech News, were there places you were expecting to see a notification of some kind and didn't see anything?

Implementing this as a forced change would be entirely unacceptable. This change must be reverted, and going forward must be solely opt-in. If you will not fork into "classic" and "responsive" Monobook, then this change needs to be stopped and rolled back entirely. Otherwise, please explain why it's not "practical". If third-party Wikimedia users want this change, they can write their own Monobook any way they like it, even using your code, but what you're doing here is NOT appropriate for the English Wikipedia and that is the flagship user of Mediawiki.

Those don't seem to be complaints about this change at all. The one at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Certain_articles_on_the_iOS_Wikipedia_app_show_wrong_images is regarding https://en.wikipedia.org/wiki/House_(TV_series), for which the infobox image is a public-domain logo. That is free content, so that could be shown. The other one regards showing sexually explicit images as the default, which may well be free content and probably are. I don't see how either one relates to this bug.

I share the view that this is a cause for concern. On en.wp, the nonfree content criteria are very clear that nonfree images can't be used solely for decoration, and may be displayed only in an article. Not on templates, special pages, interface pages, etc., only in an article.

This is far too much risk for far too little benefit. It places the user at risk, by making accessible sensitive data (as has been raised above, in some scenarios, extremely sensitive), and raises the possibility that a user could be forced to provide such data or that it could be stolen in the event of account compromise.