Overlay should not appear when an administrative page is being viewed in the parent window

Hm. This is an interesting problem. I assume you're talking about what happens if you go directly to example.com/admin/config/people/permissions by typing in the URL, instead of navigating there via an in-site link. If you get there via a link, the permissions page pops up in the overlay, and you get the correct behavior. If you type the URL in directly, though, you get the admin page in the parent window instead of in the overlay, and that's kind of unsupported behavior at the moment.

We probably should check at the time we're rewriting all the admin links, to see if the current URL is administrative. If it is, maybe we can safely assume that the user wants to navigate their admin pages in the parent window, and skip rewriting the links.

Indeed, this problem is more broad (for example, tablesorts) and I think @ksenzee's solution is correct. It would actually be useful for a number of reasons if it behaved that way when you went to a URL directly.

Alternatively, we could take the opposite approach and say that if you have the overlay toggled on and permission to use it, you should always see the overlay for appropriate pages no matter what you type ... in other words, if they type www.example.com/admin/content we could redirect them to www.example.com/#overlay=admin/content so they get the page they asked for, but in an overlay on top of the front page of their site?

At the moment I would find that incredibly annoying because I'm suffering from #615130: Overlay locks up the browser and consumes 100% of CPU for certain browsers/graphics cards/operating systems - and typing the URL directly is a workaround for that, but in the long run it might actually make more sense.... If you have the overlay turned on, you probably expect to see it consistently for a given page.

Grrr... except for one thing. Because then when they post the URL back into the forums, the URL only works correctly for people who themselves are using the overlay. This is going to get confusing.

Instead of #1

We could just leave out all overlay javascript/css when a admin page is requested without ?render=overlay

Or do what @ksenzee suggested and do the opposite of what I suggested in #666974: Open admin links without overlay using CTRL+Click.

I wouldn't like not to be able to go to admin pages directly as @David_Rothstein suggests in #4.

Or, we could do the sensible thing and remove the overlay from all base admin pages (i.e. any page you can get to from the admin menu)...

Here is a patch that prevents links opened from an administration page to open in the overlay.
Another side effect is that if you are on node/[nid]/edit and click on the "Edit" tab, it won't open the overlay but stay in the same parent page.

Was hard to figure out (to have something clean and simple without breaking other things), but in the end it was pretty simple.

I really find this behavior much better and logical than opening the overlay if we go to an admin page.
People accessing to an admin page from the parent window would be advanced users who'd have to type in the url directly, other users should not even be able to open pages directly rather than in the overlay, so the forum issue seems improbable enough.
Edit : Hmm I realize you meant the opposite, my mistake.

Moreover, I do see another issue if we did that : We would load an admin page in the main window to load it again in the overlay... Would be quite strange :)

Err, status.

If we do want this behavior (there seem to be different opinions on this; see #4) I think best implementation is to just not include the overlay-parent.js and overlay-parent.css to admin pages (as I suggested in #6).

#10 casey : About the solution proposed in #4 :

Grrr... except for one thing. Because then when they post the URL back into the forums, the URL only works correctly for people who themselves are using the overlay. This is going to get confusing.

I do see another issue if we did that : We would load an admin page in the main window to load it again in the overlay... Would be quite strange :)

I do not see how this could make sense. Besides, I find it really annoying that we are "trapped" in the overlay and have no way to navigate away from it. But that is only my own point of view.
Other opinions welcome though.

Implemented as you suggest, definitely better.

And IMHO, the overlay being all about maintaining context, it is coherent to keep the context is the parent window when we already are on an admin page.

@jide My notice about different opinions was to keep things clear, but I totally agree. Users should be able to access admin pages without the overlay and stay outside the overlay.

So I agree on your patch in #11 (although it contains a typo "no t").

Alright then, I agree we need to keep all options clear.

Typo fixed.

.

Marked #714464: Don't open a new overlay within /admin as duplicate. +1000. Patch looks good, has +1 from casey minus the typo which was fixed. RTBC.

Awesome! This definitely makes a lot more sense to me, and helps users to preserve their "site building" context, while still retaining the advantages of using overlay for quick jumps back/forth to the admin panel. Committed to HEAD.

However, I think we still need a follow-up patch, because I'm not sure how a user gets to /admin to enter the "site building" context, without typing the path into their browser manually. Hmmm..

Yes, this patch was good because the previous behavior made no sense at all - this is definitely an improvement. However, it's still pretty weird that you have this "stealth mode" that you can only get into by typing in URLs directly. Not sure if we should discuss that here or somewhere else?

The problem with opening up a "site building" context is that is that for a default install you would then get THREE different "themes" on your Drupal site:
1. Main site using Garland
2. Administration pages using Seven
3. Overlay (technically using Seven, but to the average user that's meaningless because it looks nothing like #2)

I don't think we want to give people that many different views - it's really confusing to orient yourself. That's why I suggested above that perhaps "overlay users" should always see administrative pages in the overlay. Alternatively, we could just turn off the admin theme in the default install profile (it's kind of a silly feature anyway) and then let the overlay have its own theme setting, which defaults to Seven. This would prevent Seven from being seen outside the overlay, while still allowing a "non-overlay" method of site building. This actually might make sense for a number of reasons, but I'm not sure if we really want to be adding settings at this point.

Maybe we should add an maximize button next to the close button of the overlay. This maximize button should then load the overlays iframe document into the main window.

I think most people will recognize/understand this. However they might expect an restore overlay button.

#18 :

Alternatively, we could just turn off the admin theme in the default install profile

So that would be Garland instead of Seven in the admin pages by default ? Being no fan of admin themes neither (since it is so hard to determine what an "admin page" is) that would make sense.

#19 :

That could work, but I'm not sure everybody will agree. Besides, it could mean API change, which is evil ;)

Well, I'd prefer to start a dedicated issue for discussing this, since the actual bug report here has a patch applied and is fixed, and I don't think we'll easily come to consensus about how to handle the "stealth mode" question.

OK, I went and reopened #714464: Don't open a new overlay within /admin, then (previously marked a duplicate of this one), since that one already has a start to a broader discussion.

#8: overlay-parent-admin.patch queued for re-testing.

Please don't do that.