IE8, Modal Window, Iframe Shims

[agrath]

Hi Guys

Just tracing an issue in Control.Modal
I'm using the latest RC2 of prototype, and everything is fine in IE7
and firefox.
What i'm noticing is that after the modal is closed, via modal.close,
or clicking on the overlay, links, text selection etc is no longer
available in the browser.
I've been checking a few things with the developer toolbar, and i've
found 2 things:

1) For some reason, trying to set the opacity in the iframe from the
new element call causes an 'undefined' attribute to be added with the
style information in it. This may be a prototype bug but if you
rewrite the new element line in iframeshim to read

var IframeShim = Class.create({
initialize: function() {
this.element = new Element('iframe', {
src: 'blank.htm',
frameborder: 0
});
//patched, this.element style node removed and this seperate
call added, to cause an 'undefined' attribute to -not- be added to the
iframe in ie8
this.element.setStyle({ position: 'absolute', filter:
'progid:DXImageTransform.Microsoft.Alpha(opacity:0)', display:
'none' });
$(document.body).insert(this.element);
},

This undefined element goes away.
I think it's a bit of a red heering though, because that doesn't solve
the unclickable links issue.

What i've found is it's the shims that don't appear to actually be
display:none, and thus block clicks.. even once they've been hidden by
shim.hide (which in turn calls element.hide). The display:none
attribute is in the shim's style, and I can't see anything but it's
not actually hidden properly apparently. I found that if I stripped
the rest of the code out of style tag manually, back to just
display:none and no zindex/width/height/top/left/opacity then it was
fine.

I tried calling window.destroy after I explicitly closed it, and this
removed all iframes except for the iframe shim for the Control.Overlay
- this remained. This might be by design though. If I alter the code
to force-remove this iframe shim, link functionality returns to
normal.
Unfortunately, when I closed the second modal dialog (i have a link
that opens them) (so testing the functionality a second time after
closing the first modal), I got afterClose errors from notify, so i'm
guessing it's meant to be there and forcing a remove in window.destroy
was only fixing the symptom, not the cause. I only added this as
problem solving to attempt to figure out what was happening.

Additionally, the shims navigation to javascript:void(0) causes dns
server not found content to be added as children to the iframe (e.g.
body/html etc) so I changed this to be a blank.htm page with
iframeshim in the name - this initially caused some confusion about
where they were coming from. At least in IE8.

This is probably worth a trouble ticket, but I figured i'd just post
to the group and see if anyone has had similar errors or tested in IE8
yet.

Any thoughts, suggestions etc welcome, i've been using prototype for
almost 3 years now, and this ui library looks to be really good. I'm
guessing ie8 support is on-the-way though?
How can we fix the code to stop the shims from misbehaving?

[nlloyds]

agrath,

No testing has been done with the Prototype RC or IE8, and this is the
first reported issue with either of those.

I had planned to add tickets for a 1.0.1 milestone once the existing
issues for 1.0 were resolved (almost all of which are for
Control.Window).

We're lacking a test suite at the moment, though I do have one started
on my tests branch (http://github.com/smith/livepipe-ui/tree/tests).
I'm not totally set on using JsUnitTest, we might use JsUnity or
InSpec instead.

If you can open a ticket for this on the 1.0 milestone that would
work. Sample code or tests to confirm it and any patch you might have
would help. If you have a GitHub fork you could send a pull request
and we can make sure everything works and get it integrated.

> Additionally, the shims navigation to javascript:void(0) causes dns
> server not found content to be added as children to the iframe (e.g.
> body/html etc) so I changed this to be a blank.htm page with
> iframeshim in the name - this initially caused some confusion about
> where they were coming from. At least in IE8.

There's a patch for this on the comments of Ticket #9 (http://
livepipe.lighthouseapp.com/projects/11811/tickets/9-ie6-https-control-
modal-error), so that would probably fix that issue for all IE
versions without having to add an HTML file.

> Any thoughts, suggestions etc welcome, i've been using prototype for
> almost 3 years now, and this ui library looks to be really good. I'm
> guessing ie8 support is on-the-way though?
> How can we fix the code to stop the shims from misbehaving?

Hopefully we can get something done on this soon. Thanks for your
help.

Nathan

[Gareth Evans]

Okay, i've created a slimmed down test version - you'll need to use IE8 for replication.

There should be enough info in this thread for a ticket, I haven't figured out how to use github and lighthouse yet :) (well I know how to look up tickets, but that's about it)

 

This seems to be some sort of weird IE8 CSS issue, but is definitely related to the window code.

There's a commented br at the bottom of the page, uncomment it and the bug goes away - but the layout has a space at the bottom. Regardless, i'm not sure why we'd need it and how it affects the iframes.

 

Undefined style bug - see my version of livepipe.core.js for iframeshim fix in the zip (I think it's to do with setting opacity using css string)

DNS error bug - I merged the #9 fix into livepipe.core.js

The pages are aspx, because i'm testing with visual web developer ide - and it wont allow posts to non aspx pages (html doesnt work).

Feel free to test using apache or similar, just rename the aspx files to html and get rid of the <% Page %> definition line at the top of modal.aspx and default.aspx

there is no actual code.

If you don't want to upgrade your IE8 I think Microsoft provide a virtual machine you can run with virtualpc with ie8 preinstalled and a trial of xp (or it may be vista)

here: http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en

 

See script block near top of default for my modal dialog invoke - it's invoked from a link click, but with a fake link. This is due to other behaviour, i've just replicated it with a link - normally there isn't a link when this modal dialog gets thrown.

 

Gareth

[Gareth Evans]

Oh, further to this, before I put my css layout in, I couldn't replicate the issue - odd.

[nlloyds]

Gareth,

I've looked at this some, and figured out the following:

- It seems to be an IE8-only problem, not related to the Prototype
version, since it behaves the same whether using 1.6.0 or 1.6.1.
- 2 iframeshims are inserted, but only one is hidden in IE8 in this
example.
- The modal example on livepipe.net does not exhibit this behavior, so
it's something in your example causing this.
- Removing all of the containing divs and the form also makes it work.

For now I'd just say leave the <br /> and it'll work. I don't think
I'll open a ticket until we can narrow down the cause a bit more. Hope
you can make it work for you.

Thanks,

Nathan

[Gareth Evans]

Thanks for investigating,

 

I drew the same conclusions.

No idea why the br fixes it though!

I guess it's a bit of an edge case, however the layout doesn't really do anything odd - it's all just floating with a bit of positioning, no negative margins etc.

Seems odd that some layout would cause elements to not hide/show as appropriate.

Nevertheless, there's at least a documented workaround right now, until someone else has the same problem.

 

Gareth

[Matheus S. Guedes]

First, sorry, but i don't speak english very well ok guys?
So,
I've read this post and I had the problem with modal.close on
Microsoft Internet Explorer 8 (IE8 final on Windows 7 RC1). When the
modal was closed, anything on the page wasn't able to click. So,
following the link described before by nlloyds, I found a solution
tried by "hobodave". He changed some lines on livepipe.js.
I changed this lines and worked for me. So I did change the follow
lines:

Starts on line 316 and stops on 322.
Try to change this lines for this code:

initialize: function() {
this.element = new Element('iframe',{

style:
'position:absolute;filter:progid:DXImageTransform.Microsoft.Alpha
(opacity=0);display:none',
src: 'javascript:false;document.write("");',
frameborder: 0
});
$(document.body).insert(this.element);

It worked for me and I only posted it, because maybe can help someone.
Thanks!

> > Nathan- Ocultar texto das mensagens anteriores -
>
> - Mostrar texto das mensagens anteriores -

[Gareth Evans]

Further to this, yes previously the br fix sorted it but this was a problem in a document with a strict doctype and no surrounding markup that I could see that would cause the layout bug that the <br/> seemed to be fixing last time...

 

Gareth

On Wed, Jan 13, 2010 at 9:25 PM, agrath <agr...@gmail.com> wrote:

Finally fixed this...
In another project, some months later.
in Control.Window
  open: function(event) {
....
 if (this.options.closeOnClick) {
           if (this.options.closeOnClick === true)
...
           else if (this.options.closeOnClick == 'overlay') {
//Here an overlay is loaded
               Control.Overlay.load();
...

further down
in close function...

   close: function(event) { //event may or may not be present
       if (!this.isOpen || this.notify('beforeClose', event) ===
false)
           return false;
       if (this.options.closeOnClick) {
           this.closeOnClickContainer.stopObserving('click',
this.closeHandler);
//I added this code here, because the Overlay that was .Load() further
up never got .hide() called
           if (this.options.closeOnClick == 'overlay') {
               Control.Overlay.hide();
           }
       }


Maybe this will help someone else one day.

Gareth