Overlay isn't removed after close

I can't reproduce this. Please reopen if the problem persist.

I can confirm the same behavior in D7 with the latest version. The fix does indeed work for me - thanks!

Even if this is an edge case, the addition of the extra lines above seem like a prudent addition to both D6 and D7 versions. If it doesn't hurt anything and can prevent problems later, why not go ahead and add it in?

ron

I'm still unable to replicate this. No matter how many Colorbox links I have on a page they all reuse the same #cboxOverlay and #colorbox.

Can you link to an example web site that has this problem or paste in the code you are using?

I'm having the same problem with 7, just installed the latest dev version and it's still there.

Tried to add the extra code above (starting on line 19) but that didn't work--it extended the number of times that the colorbox would work so now can get to 4th click but then the extra overlay shows up.

I have a view of 4 images from 4 different nodes, clicking the image loads the actual full node in the colorbox, i've enabled Colorbox load in the configurations, calling the URL without iframe. If I change it so iframe=true then the extra divs and overlays don't show up (following advice from http://drupal.org/node/1066146 comment #2). However, then the loaded content within the iframe stops reading my custom colorbox style .css

any more ideas????

I need to see a site with this problem before I can understand what is happening.

The site is still on my local machine--I can't go live until I've got Colorbox working. Could you be more specific about where the patch you posted above goes in the code, please? Maybe I put it in the wrong place. I inserted it on line 19, after --

$(document).bind('cbox_complete', function () {
Drupal.attachBehaviors('#cboxLoadedContent');
});

I know you have your hands full answering all the Colorbox issues, so thank you in advance!

I had this issue too, thank you for the fix. I had a Views-generated block of images, with a Colorbox link to view them larger. It worked, but if you were to click them in succession, (Click First Image/Opens Colorbox/Close, Click Second Image/Opens Colorbox/Close, etc.), then the big black overlay would stay on the screen, and no other content would visible. Using the fix took care of it.

Dolly NYC, in case you are still wondering where to place the code, here's what my full JS file looks like now:

(function ($) {

Drupal.behaviors.initColorbox = {
  attach: function (context, settings) {
    if (!$.isFunction($.colorbox)) {
      return;
    }
    $('a, area, input', context)
      .filter('.colorbox')
      .once('init-colorbox-processed')
      .colorbox(settings.colorbox);
  }
};

{
  $(document).bind('cbox_complete', function () {
    Drupal.attachBehaviors('#cboxLoadedContent');
  });
  
  //custom add, http://drupal.org/node/1057418
$(document).bind('cbox_closed', function () {
	$('#cboxOverlay').remove();
	$('#colorbox').remove();
});


}


})(jQuery);

Thank you so much for posting the code, Minneapolis Dan. I did have the fix in the right place after all. But, the fix doesn't work for me, my setup is similar to yours. The only improvement is that now I can make it to the 3rd image--so, Click Third Image/Open Colorbox/Close but then Click Fourth Image/Open Colorbox -- the stubborn overlay is back, and stays after I close that 4th colorbox. Before the stubborn overlay showed up after the Second Image/Colorbox open.

Here's a sample:

http://russell.october29.com/homepage

The fix has been added to colorbox.js

It works for 3 times (click 1st image-open colorbox-close, click 2nd image-open colorbox-close, click 3rd image-open colorbox-close) but after you click 4th time (the order of clicking doesn't matter) the overlay remains, and you can see all the extra DIVs in the code

@dolly nyc, you are using colorbox-load to load a Drupal node page without using iframe. Don't do that.

You need to load the pages in an iframe, the CSS problem you are having is a separate issue that you should be able to fix.

Instead of using colorbox-load I would try out a solution with colorbox-inline instead. In this scenario you load the nodes on the same page as the thumnails but hides them, e.g by wrapping them in a

<div class="js-hide">…</div>

(The class js-hide is used in Drupal core and vill add display: none but only if JavaScript is enabled. Very useful class.)

The thumbnail links would then look something like this:

<a class="colorbox-inline" href="?width=700&height=800&inline=true#node-4"><img typeof="foaf:Image" src="/path/to/thumbnail/image" alt="always add alt text!"></a>

The initial page will load a bit slower since the nodes now are part of the page but this means the Colorbox will open faster since the content is already there.

When displaying a page of your own website such as nodes or views it would be better if the parameter ?colorbox=yes is present to not include the colorbox javascript files. This will generate errors like the users have posted in this issue.

Please see my patch and review.

@fidodido06, handy feature. Committed to 6-dev as well as 7-dev. Only changed ?colorbox=yes to ?colorbox=no. I guess you meant "yes" to stand for "yes, this is a colorbox so don't activate colorbox here". I thought "no" as in "no colorbox active here" was a more general application.

Thanks for the patch!

that works, thank you @fidodido06 and @frjo very much! (and thank you @frjo for the module--and for your patience addressing everybody's issues!)

Patch committed on #13 does work. However, it is not nice to have to input those links if they are inside content. I have extended this so that if using colorbox and query string doesn't contain "colorbox=no" it'll be added to prevent errors. I'm not 100% sure of the approach because I suck at JS.

The patch in #12 did not work for me, but adding the four lines of code from the Issue Summary to colorbox.js worked.

Thanks!

ataxia, that's because you had to place "colorbox=no" in your links, check my patch at #16

There were no problems with Colorbox 7.x-1.0-beta1, while Colorbox 7x-1.2 seems to behave browser-dependently:
- in Firefox, it works more or less OK;
- in Chrome, the overlay is not removed after close, and you see a blank page until you reload it;
- in Opera, the pop-up box size is too small, and you cannot see the image (unless you set fixed width and height); the overlay is removed after close.

I can see the same behavior on the developer's site, which is not Drupal-powered:
http://jacklmoore.com/colorbox/example1/

P.S. Oops, sorry - it turns out that the Chrome problem with overlay not removed was caused by a Chrome extension called QR Code Generator, and the Opera problem by I have not yet found what (at least, it does not reproduce with other versions of Opera).

What worked for me is changing the Input Format to PHP code. My WYSIWYG editor was altering the ampersand in the links when it was set to Full HTML.

So, make sure your links are rendered as:

<a class="colorbox-load" href="name-of-page?width=450&height=520&iframe=true">

and not rendered as:

<a class="colorbox-load" href="name-of-page?width=450&amp;height=520&amp;iframe=true">

Hope that helps someone!
Katie

I am having this exact problem. Has anyone had any further luck with it? Adding the lines:

$(document).bind('cbox_closed', function () {
	$('#cboxOverlay').remove();
	$('#colorbox').remove();
});

to my colorbox.js file had the same effect as the others. Instead of the overlay staying after the second close, it now gets stuck after the fourth close.

Using colorbox-inline for me would be very impractical, as the nodes that it is calling are videos and it would begin downloading multiple HD videos and slow the site to a grinding halt.

Using an iframe removes the full screen functionality of video.js as videojs believes that the iframe represents the full screen dimensions. Has anyone found a way to get the overlay to consistently remove itself after the fourth close?

SR

yes same hre, it works 3 tims, fourth time it just stucks there ha hathis module is so buggy

this module is the buggiest module i have ever seen, is the developer on holiday?

I used these two links

<p><a class="colorbox-load" href="node/31?width=450&amp;height=520&amp iframe=true">link 1 iframe</a></p>
<p><a class="colorbox-load" height="520" href="node/31" iframe="true">open link 2 </a></p>

the dimensions are not accepted at all, it opens up in full screen both times, what a waste of my time

can you do same thing with lightbox 2, because this is buggy as hell and the dev should apply the patches too

@thaistore, I just tested this link:

<p><a class="colorbox-load" href="/node/31?width=450&height=520&iframe=true">link 1 iframe</a></p>

and it did open in a 450 by 520 box.

I just downloaded latest dev, I am not sure what was changed but still same problem

one time it opens up, second time black screen

what a shame, dev is not serious about this module i think

i have only few modules installed and he says he cannot recreate the problem sounds fishy to me

now i have to go and change everything back to lightbox, about 60 links

bummer

@thaistore -- look in both the open and closed issues, there were a few separate threads that collectively had several solutions to the overlay box not closing. if you dig through carefully you should find the solution that works with your individual set up. you should also look under different issue threads if you have trouble with the width and height settings instead of posting in this thread since that's a different matter. i've seen several postings about that so I'm sure you can find answers to that, too. good luck.

I was experiencing this on my site as well and although the code snippet posted in #1 helped, it didn't work in all cases. After loading a few colorboxes and closing them successfully I found that it was still presenting double overlays, then quadruple overlays and so on.

I pinpointed this down to the fact that the node page I was loading in the overlay also included a full doctype and head section which not only results in invalid HTML, but the content loaded in the overlay also includes the colorbox javascript files. In other words, each time a colorbox is opened it attempts to initialize colorbox again so now two overlays are displayed the next time around. After that, the same thing happens and each overlay in the DOM another set of overlays, explaining the exponential pattern.

tl;dr, to fix this switch to using frames in the overlay (this wasn't suitable in my case) or create some custom page templates so that only the content, not the head/body HTML is generated. You can create a custom html page template by adding this code in yourthemename_preprocess_html() in your theme's template.php (for Drupal 7+):

if (isset($_GET['embedded']) && $_GET['embedded'] == 1) {
  $vars['theme_hook_suggestions'][] = 'html__embedded';
}

Some themes use $variables instead of $vars, so substitute accordingly. This snippet makes it so that if you load a page query embedded=1, html__embedded.tpl.php is loaded instead of the default html.tpl.php. In html__embedded.tpl.php you can remove the head and body tags entirely so that only the content is presented and the colorbox JS files don't get loaded repeatedly. Now just fix your colorbox links to include ?embedded=1 in them.

Although not related to this issue, I would also recommend you implement similar code in the page preprocess function to avoid duplicate divs IDs; without a iframe the content is being loaded in to the existing page's DOM, so if you use the same html.tpl.php and page.tpl.php to generate the content inside the colorbox overlay as outside, chances are you're creating divs with duplicated IDs and that can have bizarre side effects.

Thank you franz, Your patch #16 is working.

Doesn't #16 still needs a review and to be committed?

And those keywords can go away

The main problem is people trying to open up a full web page inside a Colorbox without using iframe. As I mentioned above, don't do that.

Your options is to either simply use an iframe or implement @stewart.adam nifty solution in #28.

The patch was actually meant to address an improvement of a patch committed by yourself in #13. It has been a long time, but AFAIR this was a bug I was dealing with when using iframes.

I have been getting these issues too when using an iframe.

The patch in #12 works, but it is sad that we need to update all links to make this work. This final URL I'm using is:

/momentum-media/785?width=615&height=360&iframe=true&colorbox=no

Note that you need to use colorbox=no rather than the suggested colorbox=yes as per the patch in #12, the no & yes were changed around when this was committed.

Update:
I was using the trigger class "colorbox" and this appears to be the root cause of my issues. Changing this to "colorbox-load" made the additional paramter "colorbox=no" redundant.

So the final HTML for the link is:

<a href="/momentum-media/785?width=655&height=400&iframe=true" class="colorbox-load">HTML<a>

So there appears to be an issue with the colorbox trigger. I didn't debug this.

Also, the usage of $.once() appears a bit off: .once('init-colorbox-processed') adds the class 'init-colorbox-processed-processed'. It is cleaner just to use .once('init-colorbox') that creates the class "init-colorbox-processed".

Another technique to solve this, in addition to just using iframe or doing #28 is to setup your own AHAH-ish callback. For instance, say you want a views page to be embedded in the colorbox.

You can create your own hook_menu item for the colorbox link and then create your own callback that manually renders the view page and prints it. When colorbox, using ajax, grabs that page's content, what's returned is just the html for the view not the entire page html. This is what this technique looks like:

/**
 * Implements hook_menu().
 */
function YOUR_MODULE_menu() {

  $items = array();

  $items['admin/ahah'] = array(
    'title' => 'Colorbox AHAH-ish technique',
    'page callback' => 'YOUR_MODULE_ahah',
    'access callback' => 'user_is_logged_in',
    'type' => MENU_CALLBACK,
  );

  return $items;

}

/**
 * Colorbox AHAH-ish callback to manually print a view's HTML output to be
 * grabbed by Colorbox using its AJAX technique.
 */
function YOUR_MODULE_ahah() {

  print views_embed_view('your_view', 'page_1');

}

In this case, your colorbox link might look like this:

<a class="colorbox-load" href="http://example.com/admin/ahah?width=2000&height=1500">your view</a>

This problem still appears to happen exactly as shown in the example image from #1. This occurs also on the newest 7.x-2.x-dev.

In my environment I am overriding a jquery onclick function provided by the Views jQFX Imageflow module as follows:

function() {jQuery.colorbox({href:this.url,title:this.title});}

This can be added to the view while configuring it.

Exactly as described in #1, every time I open a new colorbox overlay, it is duplicated in the code which brings the site to a crawl after opening 5 or 6 successively.

I tried both patches (#12, #16) without luck. Any suggestions? Thanks!

Nevermind, this also works as designed. I changed:

function() {jQuery.colorbox({href:this.url,title:this.title});}

to

function() {jQuery.colorbox({href:this.url,title:this.title,iframe:true});}

This is thanks to #34 for inspiration.

Edit: Also the Colorbox Node module is a great alternative that loads it inline, and closes out the colorbox overlay correctly, all without using an iframe.

adding the code in the issue description to colorbox.js helped my case. I have a view-generated list of node titles, that can be expanded into full nodes by clicking the titles with the help of the jQuery AJAX Load module. In these full nodes I have image thumbs that can be viewed using colorbox gallery. Before the code was added, the gallery from the first node had no problem, but opening different nodes from the list and browsing their galleries generated duplicate copy of the first image from the gallery into the overlay that is normally positioned between the image and the page from which it was launched. Adding the code removes the extra "image overlay".