Steps to reproduce this issue:

1. Set Garland as the default theme.
2. Set the admin theme to the Default theme.

OR:

1. Just set Garland to be the admin theme.

Then:

Click "Configuration" in the Toolbar - the overlay will start to load then stop and the page loads in standard Garland. Thereafter you are out of the overlay - you have navigate back to the homepage (or a non admin page) before you can get back in the Overlay. Overlay seems to work for some admin pages, but not others. E.g "Content" seems to work OK, but "Configuration" and "Reports" bump you out of the Overlay.

I can't seem to reproduce this for any other theme or combination of core themes (front end + admin theme combos).

CommentFileSizeAuthor
#3 garland-tabs.patch2.69 KBJeff Burnz

Comments

bleen’s picture

bleen commented

I can confirm this bug ... weird!

David_Rothstein’s picture

David_Rothstein commented

Weird bug indeed.

Here is a start at debugging it - I know that the overlay parent JavaScript has some code in Drupal.overlay.loadChild() to force the child window to break out of the overlay if the child window finishes loading and doesn't have the overlay JavaScript in it. This can presumably happen if there is an error on the child page.

Sure enough, if I comment out that code and then look at the resulting page in Firebug, there is an error message inside the overlay:

Fatal error: Cannot unset string offsets in ....modules/overlay/overlay.module on line 353

That points to this code:

/**
 * Implements hook_preprocess_page().
 *
 * Hide tabs inside the overlay.
 *
 * @see overlay_get_mode()
 */
function overlay_preprocess_page(&$variables) {
  if (overlay_get_mode() == 'child') {
    unset($variables['tabs'][0]);
  }
}

I haven't looked into it any further, but I guess it must mean that on some pages (I assume pages without any local tasks?), Garland is doing something with the $tabs variable that the overlay doesn't expect...

Jeff Burnz’s picture

Jeff Burnz commented
StatusFileSize
new garland-tabs.patch2.69 KB

Indeed, I am not sure exactly what the issue is (haven't dug in either) but a quick play around changing garlands tabs to this (the patch - set variables for tabs like Seven does) does seem to solve the issue...

David_Rothstein’s picture

David_Rothstein commented
Status: Active » Needs review

Hm. Seems like something very funny is going on... In any case, setting to "needs review" :)

Jeff Burnz’s picture

Jeff Burnz commented
Issue tags: +Garland-Overlay

tagging

bojanz’s picture

bojanz commented

Okay, so the patch looks fine and makes Garland behave like Bartik in this regard.

The question is: can we make the Overlay less fragile in this regard? I really don't like the thought of debugging something like this in my own theme...
Or is this just the case of Garland doing things wrongly?

idflood’s picture

idflood commented

I wanted to work on this issue and was not able to reproduce the bug. while looking at the sources, i've found that the code in #2 has changed to:

function overlay_preprocess_page(&$variables) {
  if (overlay_get_mode() == 'child') {
    unset($variables['tabs']['#primary']);
  }
}

This modification seems to fix the child page error. I've also tested with stark theme and everything is working fine.

catch’s picture

catch
he/him
Primary language English
commented
Status: Needs review » Closed (cannot reproduce)

Closing per #7, looks like it was fixed elsewhere.