Last modified: 2014-02-12 23:45:25 UTC
On a image description page using the mobile frontend via a normal browser (Firefox 22 in my case), clicking on the image, even though there are higher resolutions, doesn't do anything. See http://en.m.wikipedia.org/wiki/File:Gomek.jpg for example
This is intentional and has been the case since the beginning of mobile time. Only the image link is disabled. This is to avoid accidents of clicking through unintentionally. You can still access the higher image resolution links below and right click (or hold down press on mobile) to access the link. I'd say this is the correct behaviour but am open to further discussion. See original commit: commit af42cb8324d3bc8508c57fdde475e305fc34158f Author: Brion Vibber <brion@users.mediawiki.org> Date: Sat Dec 10 19:30:47 2011 +0000 Initial commit of improved file page for MobileFrontend Please test on various devices; may need to be altered or removed for devices with less-capable browsers, but might work fine. Known good on iOS 5 and Android 2.3 browsers. Based on previous mockup work. Reformats the filetoc list and turns the links into toggles for which section to show. Each section shows by itself, so a wide history table doesn't hose the rest of the page. Image is fit to the screen, but still using the larger-size screen thumbnail so looks nice and high-res and zoomable. Disables clickthrough on the image (can still copy the link etc, but tapping won't shove you through to the raw image by accident. You can still tap on the detail links, Similar improvements should be brought to the desktop site, perhaps. :)
That's why I've almost gone mad on my phone when trying to open a image, tapping on the image million of time. I always assumed it was a bug in the browser I used on my phone. Never realized it was a improvement imo this behavior should be changed to either return to a clickable link, or remove all traces of a link so people don't get mad when trying to open it.
... but it's not clear that the image itself is a link unless you know that it is on desktop (it is not styled as one). Looking at the mobile site of Flickr they do a similar thing: http://m.flickr.com/#/photos/38177739@N05/8857797888/in/explore-1369690180/ I still think this is the right behaviour as it is extreemmmeelly annoying to accidentally click on an image whilst zooming into it (especially if you are on a limited data tariff) but think we could improve things by removing the link in the html output (although since this involves the parser I imagine this is extremely tricky). We could however instead of disabling the link just remove traces of it in javascript. I will wait for Brion to chip in since he wrote the original implementation and might be able to shed more light.
Yeah... I think the current behavior is pretty strange. There _is_ a link, as you note: --- <div class="fullImageLink" id="file"><a href="//upload.wikimedia.org/wikipedia/en/5/56/Gomek.jpg"><img alt="File:Gomek.jpg" src="//upload.wikimedia.org/wikipedia/en/thumb/5/56/Gomek.jpg/484px-Gomek.jpg" width="484" height="600"></a> --- But this link is being intentionally disabled with JavaScript. This can be a pretty nasty trick on the user. On any device with a cursor, the image appears clickable on-hover, but it really isn't. Oww. If we assume that the people most worried about data usage are on devices without JavaScript, the remnant link continues to work. Not great either. Arguably kind of the opposite of graceful degradation. The inconsistent behavior between desktop and mobile, and between devices with or without JavaScript support, certainly seems like a bug to me. Regardless of the good intention (preventing people from accidentally clicking the image when they just want to zoom in), we're pretty clearly defying user expectations here. File description pages had click-through to the raw image long before December 2011. :-)
Marking as an enhancement as we need some design input and discussion around what the correct behaviour should be.
So the JS hack on MobileFrontend was put in quite a while ago becausing accidentally tapping through was too easy to do and gave a useless experience with extra loading of a huge multi-megabyte image. Bug as written "clicking on image on description page doesn't do anything" is a WONTFIX; please replace with something like "make images do something useful when clicked from an article".
(In reply to comment #6) > Bug as written "clicking on image on description page doesn't do anything" > is a WONTFIX; please replace with something like "make images do something > useful when clicked from an article". Ehhhhhh. Not to poke the bear, but I'm going to re-open this for further consideration. The HTML output (combined with the _need_ for a JavaScript hack) seems like a plain and simple bug to me, unless there's some good reason for wrapping the <img> in an <a> and then disabling it. (Is there?) Jon seemed to indicate in comment 3 that the current approach (which I'd probably describe as a hack, though again, I'm shooting in the dark a little) was taken due to a limitation in the MediaWiki parser. If this is a limitation in the MediaWiki parser, this bug could probably just have its product/component updated.
How about just tab it, and then give a warning if the image is bigger than $1 kilobytes, before loading the page ?
Given comment 6 and the fact that Carl just opened bug 48996, I'm re-closing this as WONTFIX
I think one bug report is enough for addressing this problem. I think a lot of Carl's arguments stand but I'm going to reply on the other bug. Sorry for any confusion.
