Reverse the overlay implementation (put the parent page in an iframe underneath the administrative page)

@Casey

This is an interesting idea. I am however not convinced that the parent page will be left out of the accessibility tree for screen-reader users.

In Safari with VoiceOver this will be an inprovement, as VO will see all of the overlay content and the user will have to interact with the frame to find the parent content.

With JAWS (I am not sure about other screen-readers), all of the parent frame will likely still be placed in the buffer. I don't imagine that setting the tabindex to -1 will hide the iFrame contents from JAWS. But, I can test if you want to make a test page containing an iFrame with some content and its tab index set to -1

subscribing

Wow. This is intriguing.

I remember we discussed at one point that we'd simplify the code a lot if we just reloaded the page every time a form was submitted rather than trying to detect changes, but this takes that idea to a whole new level and then some. Impressive job :) The concern then was the same as casey mentions above, that these full page rebuilds might look too weird to the user on certain browsers. And with the current overlay I think that is the case, but because this patch removes all the JavaScript (!) from the overlay that doesn't seem to be an issue anymore. I tested it on a few different browsers and the reloads all looked pretty smooth to me.

Like Everett I'm not totally sure I understand how this solves the accessibility issues (at least not with the tabindex change alone) but by sandboxing all the "unwanted" content inside a single iframe it seems like it can only help. So one of the toughest problems before was that there are so many ways screen readers can jump to different text on the page - e.g., you can tell it to jump to the next paragraph, or next h3 heading, or whatever, and we were trying to catch all those. But if you tell it to jump to the next paragraph and the next thing is an iframe will a screen reader like JAWS really cross silently into the iframe and jump to a paragraph in there? I guess that is what is worth testing.

The patch no longer applied so here is a straight reroll (attached).

232 insertions, 1638 deletions.

You must be joking?

subscribing

First impressions:

PRO
----
- IT IS INCREDIBLY FAST

CON
----
- behind the overlay you see the page loading again for every page, *very* *very* annoying.
- on switching: when there is a small lag you get a white screen for a sec just like any non overlay pages.

BUG
----
You deleted some code that put the "add to shotcuts" behind the title

- behind the overlay you see the page loading again for every page, *very* *very* annoying.

I noticed that too (sometimes) but that seems to be a bug. The intention of @casey's patch is that the reload only happens on e.g. form submissions and the like, not all the time. While testing it out, sometimes it worked that way for me, but other times it didn't, so there's probably just a bug in there we need to track down.

You deleted some code that put the "add to shotcuts" behind the title

There's an issue at #782652: Shortcut-specific code shouldn't be in the Overlay module that would make that work, and it's a good idea in its own right (and probably not a hard patch, just haven't tried writing it yet though). @casey's patch here just reveals what any other module besides the shortcut module is going to experience anyway if they try to attach something to the page title, so it's a good argument for why that other issue should be fixed :)

I also noticed this: on switching: when there is a small lag you get a white screen for a sec just like any non overlay pages..

Added it to my previous post

Cons:
* Parent page is reloaded every time another overlay page is visited

Isn't this the cause of the reload?

I tested the patch in #5 with JAWS 11.0.756 / FF 3.6.8 and VoiceOver (OS X 10.6.3) / Safari 4.0.4

JAWS parsed all content into the same virtual buffer, meaning that all of the underlying page content in the iFrame is still available to the user.

VoiceOver only presented the frame as a single object in the DOM that the user would need to interact with to read the content. However, if the user were to interact they would be confused by the fact that the toolbar and other content would appear to be duplicated twice on the page.

If this is ever going to work, please include this into a new overlay-rtl.css.

#overlay {
  padding-right: 0px;
  padding-left: 26px;
}
#overlay-title {
  float: right;
}
#overlay-close-wrapper {
  right: auto;
  left: 0;
}
#overlay-close,
#overlay-close:hover {
  background: transparent url(images/close-rtl.png) no-repeat;
  -moz-border-radius-topright: 0;
  -webkit-border-top-right-radius: 0;
  border-top-right-radius: 0;
}

/**
 * Tabs on the overlay.
 */
#overlay-tabs {
  left: 20px;
  right: auto;
}

I just tested this patch against some of the issues reported in http://drupal.org/node/655388 and it solves them, e.g. the problem of clicking on 'More information about text formats' while adding/editing a node in overlay and losing every change you made in your form.

Regarding #10 and #8: I don't see the white flashing and also don't think the page reloads of the parent page (background) are really noticeable due to the very dark overlay.

Big ++ for going forward with this.

Is there any reason we can't do everything on one page - e.g., only load a new page once, on the opening of the overlay. The overlay then opens on the main part of the new page, with the old page in an iframe in the background. Then when the overlay moves around, e.g. a form submits, or a link is clicked, the overlay is reloaded through javascript -- not an iframe. Not sure if this makes sense or if it does whether it's too much code to be viable, but perhaps worth considering.

subscribe

@Casey

I am not sure if embedding the underlying document in an would be effective, but I can test. Otherwise the most important issue for D7 release is connecting a link from the Overlay to the user profile / edit page where it can be disabled.

@Casey

Curious where you found the info that content of object is included in accessibility tree? Can you please provide more details?

This was a demonstration to assess if reversing the Overlay would aid accessibility. We are looking at a different route, setting to wn't fix.

Wait... why? There are tons and tons of possible benefits from this patch.

Granted, I think the chances of this getting into Drupal 7 (at least Drupal 7 core, that is) are pretty slim at this point, but I don't think it should be "won't fix" overall.

@David

Thanks for reopening this. I was only looking at it from an accessibility perspective. If there are other possible benefits then it's good for it to be reopened.

Bumping to D8. We are on beta2, I don't see this getting into D7.

Subscribe. Is the overlay-context needed at all, or just for visualization pleasure? We have an overlay of 90% window size, thus the overlay-context can be replaced with a "fake background".

I'll take a more careful look at this now that the Drupal 8 branch is open. The idea definitely has merit, and now is the time for total rewrites like this.

Out of date.

In what way is it out of date?

It still seems relevant to me, but I don't think it can really happen for Drupal 8 at this point, so moving to Drupal 9.

More descriptive title.

Overlay has been removed from core so this is no longer an issue that needs resolved. #2088121: Remove Overlay