Mar 17 2020
Yes, the fix has already been deployed and confirmed to work.
@Dvorapa: Yes, this was fixed some time ago.
Dec 9 2019
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.
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.
Dec 7 2019
I note that this was intended to have a fix, but I'm still receiving the same error on the English Wikipedia.
Nov 28 2019
Sep 10 2019
So far as the question by @MMiller_WMF , I use the desktop version because:
Sep 6 2019
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.
Aug 29 2019
I can confirm that I've had this issue as well.
Apr 29 2019
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?
Jun 4 2018
Jun 3 2018
Jun 2 2018
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.
Mar 23 2016
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.
Jan 30 2016
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.
Apr 6 2015
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.