JavaScript failure in overlay-child.js

FWIW, I had this issue in the Modal Frame API queue, related to jQuery Tabs, and I fixed it by adding the child behavior on top of all existing behaviors in the global Drupal object. That way, the content of the child document is already visible when other behaviors are executed.

Related issue in the Modal Frame API queue: #608472: jQuery Tabs in Modal Frame do not work because the child document is not visible until the child Drupal behavior is executed

That particular patch can be found here: patch

I think that was the best solution to this problem, because the same issue could also affect other modules, not just the Vertical Tabs behavior.

In my case, the problem was that jQuery Tabs was unable to get the size of certain elements because they were not visible at the time the behavior was executed.

I think this could be related.

+++ modules/overlay/overlay-child.js	2 Dec 2009 08:02:33 -0000
@@ -107,7 +107,7 @@ Drupal.overlayChild.behaviors.scrollToTo
-  $('a:not(.overlay-exclude)', context).once('overlay').each(function () {
+  $('a:not(.overlay-exclude).not(.overlay-processed)', context).once('overlay').each(function () {

errrrrr...... this is duplicating what $.once() already does. If this has an effect, then it's just by coincidence.

errrrrrrrrrrrrrrrrrrr... oh my. $.once() takes the function to invoke with $.each() as second argument. So just kill ").each(" here.

This review is powered by Dreditor.

As Sun mentioned above, this should do it:

Index: modules/overlay/overlay-child.js
===================================================================
RCS file: /cvs/drupal/drupal/modules/overlay/overlay-child.js,v
retrieving revision 1.1
diff -u -p -r1.1 overlay-child.js
--- modules/overlay/overlay-child.js	2 Dec 2009 07:28:22 -0000	1.1
+++ modules/overlay/overlay-child.js	2 Dec 2009 08:02:33 -0000
@@ -107,7 +107,7 @@ Drupal.overlayChild.behaviors.scrollToTo
  * @see Drupal.overlay.isAdminLink()
  */
 Drupal.overlayChild.behaviors.parseLinks = function (context, settings) {
-  $('a:not(.overlay-exclude)', context).once('overlay').each(function () {
-  $('a:not(.overlay-exclude)', context).once('overlay', function () {
     // Non-admin links should close the overlay and open in the main window.
     if (!parent.Drupal.overlay.isAdminLink(this.href)) {
       $(this).click(function () {

......... Looking at this, it seems like the Overlay will execute on every a tag on the page. If you're on a page with 1000 a tags, then this function will have to add overlay-processed to each one of those elements. Would it be a better idea to use $('a.overlay-include').once('overlay', ... instead so that we don't have that front-end performance hit? Instead of applying the Overlay to everything except X, shouldn't we instead simply apply the Overlay to Y and not worry about the exceptions/exclusions?

omg... why don't we use the observer pattern as implemented by quicksketch in Google Analyics module?

http://drupalcode.org/viewvc/drupal/contributions/modules/google_analyti...

@Rob Loach: how do you tell from PHP which links should be included in the overlay and how do you tell these for JS generated markup, stuff that was built based on JSON requests, etc?

@sun: tracking document clicks and looking at the element clicked does indeed seem to be a good idea.

You're right, Gabor, links could be generated anywhere (PHP or JavaScript) without being considered by the Overlay's PHP layer. If we apply the observer approach here, it might be a good solution around it.

This is fixed per #174 in #615130: Overlay locks up the browser and consumes 100% of CPU for certain browsers/graphics cards/operating systems.

Anyone who can still reproduce it is free to reopen.