This is the talk page for discussing improvements to the NoImageLightbox page.


I've only done a handful of tests, but it seems setting

window.wgEnableLightboxExt = false;

is all that's needed to prevent the Lightbox extension from loading in the first place. -- pecoes 17:29, November 09, 2012 (UTC)

The Lightbox is used for videos too, however. My version of NoImageLightbox has the goal of disabling the Lightbox only for images.
Expected behavior for videos:
  • If you left-click the video, it should play normally within the Lightbox.
  • If you right-click and choose "Open link in new tab" you will get to the File: page.
20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 17:38 UTC, Friday, 9 November 2012
Oh. Right. I only read the first sentence of the addon description and jumped directly to the code. Then I saw those timeouts and couldn't believe my eyes :D -- pecoes 17:47, November 09, 2012 (UTC)
The setTimeouts have nothing to do with videos. Those exist because:
  • I need to modify Wikia's global window.LightboxLoader variable
  • At the time of writing the script, I was encountering errors with my script not working because it was running too early -- before window.LightboxLoader was defined.
  • The setTimeouts are the solution designed for that problem.
I suspect the setTimeouts aren't needed / that problem doesn't exist anymore / it was a fluke on my end or something. I'll try removing setTimeouts and see what happens. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 17:59 UTC, Friday, 9 November 2012

(Reset indent) May I suggest to remove that click-handler as well?

if ({ oasis: 1, wikia: 1 }[mediaWiki.config.get('skin')]) {
    jQuery(function ($) {
        "use strict";
        if (!window.LightboxLoader || window.LightboxLoader.handleClickOverride) return;
        window.LightboxLoader.handleClickOverride = window.LightboxLoader.handleClick;
        window.LightboxLoader.handleClick = function (ev) {
            if ($('video')) {
                window.LightboxLoader.handleClickOverride.apply(this, arguments);
        // href to File: page, but not for images that have the link= set, e.g. [[File:Image.png|link=MyPage]]
        .each(function () {
            var $this = $(this),
                e = encodeURIComponent($this.attr('data-image-name').replace(/ /g, '_'));
            $this.attr('href', '/wiki/File:' + e);
-- pecoes 18:19, November 09, 2012 (UTC)
I'm not familiar with how to go backwards from "I have an event object, now how do I figure out the element that triggered it" -- it looks like that's what you're trying to do, which is pretty cool. Sadly, I tested your code in both Chrome and Firefox at FloatingToc and it didn't work: left-clicking the video took me to the file page instead of playing the video in the Lightbox. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 18:37 UTC, Friday, 9 November 2012
Hm. It seems to be $( Not $( itself. -- pecoes 19:10, November 09, 2012 (UTC)
Okay, I've tested and incorporated that change. Thanks. I never considered that it was possible figure out which element an event originated from (hence my click handler construction), I thought that elements triggering events was a one-way street and once the event is triggered, there's no discerning where it came from. I suppose I should go actually read the documentation for both native event objects and jQuery's wrapper jQuery.Event. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 19:44 UTC, Friday, 9 November 2012

Script Has Stopped Working

The script seems to have stopped working over the past few days. The Lightbox is appearing in the most recent versions of both Firefox and Chrome.

--Whistle9 (Talk) 19:31, April 20, 2013 (UTC)

Thanks for reporting this. Looks like Wikia has made some small changes to HTML attributes for Lightbox media pieces. I've pushed a re-write of the script that should address those changes, and the updated version is working for me in all tests so far. There is also a new option I've added to disable the Lightbox for videos as well as images (by default, this script is not meant to affect videos).
Please let me know if the fixes don't seem to be working or if the entire script breaks again. Thanks! 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 23:41 UTC, Saturday, 20 April 2013


Usually when I see an image, I Ctrl+Click it to open in new tab (I use Chrome btw). However, Ctrl+Click, normally working on links (and images that are on file namespace pages), does not work with this script. Instead, it opens in the same tab as though you just single-clicked it normally. Would it be possible to look into this and see if there is any way to "fix" it?

Also, Chrome's "Open link in new tab", when applying to Wikia images, lead you to a page with just the image (e.g. I prefer being led to File:ListFiles.png instead of [1]. Is it possible for a script to be written/modified so that it leads to the File page instead? — SW8573 (Talk) 13:55, April 26, 2013 (UTC)

These two issues have the same root cause, incidentally. Implementation wise, NoImageLightbox does not treat clicking on an image as clicking a link. Instead, it uses an event to redirect the browser to the File: page. This is why CTRL + click doesn't work properly.
This is undoubtedly poor design, but unfortunately due to the way Wikia's lightbox event handling is set up — as of recent changes within the past week or two — I have not been able to find an implementation that 1) allows the lightbox event to continue to work for videos AND simultaneously 2) kill the lightbox event for images only so that it is ignored and clicking an image is simply the same as clicking a link. Wikia uses the same lightbox for both images and videos, so it's tricky to separate the two. But separating them is exactly the aim of the default functionality of this script.
The right-click -> "Open link in new tab" issue has been fixed, that will now take you to the File: page as intended.
CTRL + click opening a link in a new tab instead of the same window cannot be fixed without coming up with a new implementation that satisfies the 2 conditions I listed above — which, if possible, I lack the event-based knowledge to do. Maybe someone else who reviews this script can suggest a more intelligent event-based approach. Otherwise, this CTRL + click bug probably won't be fixed in the near future.
Note: If you absolutely must have the CTRL + click functionality, use the config option described on the page. That option is a 2nd implementation of NoImageLightbox that doesn't suffer from this issue. You will be able to CTRL + click properly with that option. —However, videos will not play on articles. If you don't care about videos that should be fine. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 02:56 UTC, Saturday, 27 April 2013
Update — apparently there was a rather simple solution, I just wasn't aware of it. Thanks to Pecoes for pointing me in a better direction. Ignore the above, both of these issues should now be fixed. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 15:23 UTC, Saturday, 27 April 2013
Community content is available under CC-BY-SA unless otherwise noted.

Fandom may earn an affiliate commission on sales made from links on this page.

Stream the best stories.

Fandom may earn an affiliate commission on sales made from links on this page.

Get Disney+