Tue, Sep 10
So far as the question by @MMiller_WMF , I use the desktop version because:
Fri, Sep 6
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.
Thu, Aug 29
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.