Last modified: 2014-02-13 08:58:40 UTC
Opening the viewer lightbox doesn't affect the URL or browser history, so you can't easily save or share a link to an image you're viewing: if you just bookmark or copy-paste the link from your URL bar, when the link is opened you'll just see an article... If you're in the know you can copy that "Learn more" link or manually right-click and pull up the raw image, but these are.... not pretty. :) Could append a hash parameter on the URL (using history.pushState()/popState() when available) specifying the image to show in lightbox, and have a magic handler to open a popup on load if such a hash is specified. something like https://en.wikipedia.org/wiki/San_Francisco#mediaview=File:SF_From_Marin_Highlands3.jpg ?
This sounds like a desirable thing, yes :) Thanks for the idea!
Alternatively, we could push the URL of the image description page, that way sharing the link with others who have javascript/MultimediaViewer disabled would have more consistent behavior. (On the other hand, refreshing the page with the viewer open would behave more surprisingly.)
*** Bug 56493 has been marked as a duplicate of this bug. ***
I too have been struggling with the lack of direct link to open a file in Media Viewer. It's a serious issue for me, because it makes it hard to share links to large versions of images, which is a very common use case across the Internet. To address this issue, I am increasing the priority of this ticket, and cross-linking it with this feature request #67 on Mingle: https://mingle.corp.wikimedia.org/projects/multimedia/cards/67 While it is possible to send people to the file pages on Commons, it's a cumbersome process as Brion points out, and the file pages are too cluttered to be an acceptable destination for sharing files with casual users.
Change 97657 had a related patch set uploaded by MarkTraceur: Push history state to support links to media viewer https://gerrit.wikimedia.org/r/97657
The implementation is: 1. You can load with #mediaviewer/File:Test file.jpg/1 and it will auto-load that file for you IF File:Test file.jpg is the 1th (0-indexed) image on the page. If the page has changed, it will just ignore the hash fragment and load the page normally. 2. Your URL will change when you open the lightbox, and you can use the URL in the location bar to link to your current state. 3. You can press the back button in the lightbox to close the lightbox, and if you've closed the lightbox with the escape button or the close button, you can use the back button to reopen it. Hitting the back button more than once doesn't work currently and I have no idea why. 4. If there are weird characters in the file name, I have no idea what will happen. Yay uncertainty! For #1, I can stop checking if we prefer to just blindly load the nth image if we're given #mediaviewer/n as the hash fragment (as long as it's a number, of course).
- IMO the same link should not point to completely different things at different points in time, so including the file name is a good idea. - not so sure about the number; this would break the link when an unrelated part of the article or is edited (even worse for categories). I would rather index images of the same name only (if we don't show page-based metadata like the subtitle, even that is unnecessary). - file names might contain a /, so filename|index or filename[index] would be a better pattern Do we want to do anything useful for non-JS-enabled browsers? The pushstate API would make it possible to redirect them to the image description page; I'm not sure if that would make sense.
Change 97657 merged by jenkins-bot: Push history state to support links to media viewer https://gerrit.wikimedia.org/r/97657
Patch was merged a while ago - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
The original issue has been addressed. Moved other, loosely related ideas to https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/206
