Last modified: 2014-02-12 23:48:08 UTC
When, via the mobile frontend, trying to open a image using the "Full resolution" link, the software fails due to missing prefix, and tries to open a normal wiki page instead. i.e. going to [en:w:File:Benz-velo.jpg]] and choosing "full resolution" you end up at [[en:w:Benzo-velo.jpg]]
Do you have an example URL?
I'm able to reproduce this bug. Go to <http://en.m.wikipedia.org/wiki/Cidade_dos_Homens_4.jpg> in a Web browser with JavaScript enabled. When you click the "Cidade_dos_Homens_4.jpg" link below the image, it'll lead to <http://en.m.wikipedia.org/wiki/Cidade_dos_Homens_4.jpg>. This is wrong. Workaround is to disable JavaScript. The underlying HTML is fine. Something funky with a JavaScript script going on, I believe.
<http://en.m.wikipedia.org/wiki/Cidade_dos_Homens_4.jpg> doesn't exist. Did you mean <http://en.m.wikipedia.org/wiki/File:Cidade_dos_Homens_4.jpg>? This page shows "No higher resolution available." so there's no "Full resolution" link to click... if there was one, it should go to the image JPG directly so there wouldn't be any 'File:' prefix on it.
(In reply to comment #3) > <http://en.m.wikipedia.org/wiki/Cidade_dos_Homens_4.jpg> doesn't exist. > > Did you mean <http://en.m.wikipedia.org/wiki/File:Cidade_dos_Homens_4.jpg>? Eep, sorry about that, yes. Steps to reproduce: 1. Go to <http://en.m.wikipedia.org/wiki/File:Cidade_dos_Homens_4.jpg> in a browser with JavaScript enabled. 2. Click the "Cidade_dos_Homens_4.jpg" link below the image (next to the text "(400 × 566 pixels, file size: 40 KB, MIME type: image/jpeg)"). You'll be incorrectly directed to <http://en.m.wikipedia.org/wiki/Cidade_dos_Homens_4.jpg>. I've confirmed using Safari (on a desktop Mac and on my phone) with and without JavaScript disabled that this is definitely JavaScript-related. With JavaScript enabled, the working (and correct) link to upload.wikimedia.org is somehow being hijacked. With JavaScript disabled, I'm correctly directed to <http://upload.wikimedia.org/wikipedia/en/1/14/Cidade_dos_Homens_4.jpg>.
This is related to bug 43539 This bug should be limited to beta in resolution of that bug.
Specifically the problem lies in the fact that the title attribute has value Cidade dos Homens 4.jpg rather than File:Cidade dos Homens 4.jpg Is there any reason it is this way? Surely the title attribute should be consistent across namespaces? Currently some code in the beta which has leaked into mobile (patch in gerrit for that) is relying on the title attribute for the name of the page. If the title attribute is not sufficient it would be useful to add a data-title attribute for these purposes.
(In reply to comment #6) > Specifically the problem lies in the fact that the title attribute has value > Cidade dos Homens 4.jpg rather than File:Cidade dos Homens 4.jpg Relevant HTML: --- <div class="fullMedia"><a href="//upload.wikimedia.org/wikipedia/en/1/14/Cidade_dos_Homens_4.jpg" class="internal" title="Cidade dos Homens 4.jpg">Cidade_dos_Homens_4.jpg</a> <span class="fileInfo">(400 × 566 pixels, file size: 40 KB, MIME type: image/jpeg)</span> </div> --- > Is there any reason it is this way? NFI. > Surely the title attribute should be consistent across namespaces? Maybe (expanded on below). > Currently some code in the beta which has leaked into mobile (patch in gerrit > for that) is relying on the title attribute for the name of the page. If the > title attribute is not sufficient it would be useful to add a data-title > attribute for these purposes. I'd prefer that a data-title attribute be used. It looks like the current title attribute is the unprefixed file name without underscores. I'm not sure why this is or what value the title attribute provides to anyone currently, but a custom attribute would be much saner here, I think.
I think the data-title attribute is the way to go. It will however require a chance to core in how links are outputted by the parser. I was hoping to avoid this but I guess we have little choice now other than piling on more hacks!
Lazy loading code has been removed as of https://gerrit.wikimedia.org/r/#/c/62940/ so this bug is no longer present. Code is undergoing a big rewrite.