"c.defaultView.getComputedStyle() is null" issue in Firefox - javascript

I'm using jquery in a page on domain "abc.com", and this page opens an iframe on domain "def.com", which also uses jquery (same version, and I tried different ones from 1.5.2 to 1.6.4). The frame is opened using the jquery library thickbox (not maintained anymore...).
My problem occurs in Firefox (any version from 3.X to 8.0), where I get the javascript error "c.defaultView.getComputedStyle(a, null) is null" the first time I load the iframe, and thus can't access any jquery initialization method:
$(function() {
/* Does not pass here in firefox */
});
On any other browser (chrome, ie, opera...) the code works, but in firefox I have to reload manually the iframe (right click -> this frame -> reload)... I have read some posts here on SO about similar issues, and each time the problem is a conflict between the two jquery libraries. In my case I can't remove one of the JS because the two pages are on different domains.
Thanks for your help.

This is related to the following Firefox bug:
Bug 548397 - window.getComputedStyle() returns null inside an iframe with display: none
Possible solutions include setting the iframe's width and height to 0 or visibility to hidden, rather than using display: none.

Related

Iframe does not fully load in all IE versions

I am trying to load an iframe, get an part of his content and delete the iframe.
My solution works on FF, Chrome but fails sometimes in all IE versions.
When I load an page in browser I see the its full content, but when I load exactly the same page in iframe there are missing elements from the page.
I've tried to add the iframe by hand from console and sometimes the page load all its content ,some times it doesn't.
Does anyone have a clue why does this happen?
i believe that not declaring DOCTYPE (in both the iframe source and the parent) can cause issues like that.
undeclared doctypes can cause the browser to revert to quirks mode

Strange JavaScript errors in IE9

We have a website (asp.net, C# 3.5, Ajax Control Toolkit 3.5, jQuery 1.3.2) it is working fine in IE8 (also OK in Fire Fox and Google Chrome).
But our client asked us to make it IE9 compatible, when we tested it in IE9 it gives strange errors. Like SCRIPT5009: 'Function' is undefined', Array is undefine, object is undefined, means it says even native javascript object/functions are undefined.
Errors occur on those pages where there are IFrames embedded (good or bad but we can't remove IFrames from those pages).
After doing some R&D people said that IE9 has feature/bug related to IFrames (it was something like that if we change the position of IFrame in DOM after loading the page then IE9 re-initialize the IFrame to prevent memory leaks), we have IFrames inside Collapsible extenders of Ajax Control Toolkit, I don't think that expand/collapse extender changes the position of IFrame in the DOM instead of show/hide. But to overcome this what we did is that we deffered setting the src of IFrames until the page is rendered on client side and DOM is fully ready ( we used the pageLaod client side function of Ajax Control Toolkit) here we set the src of IFrames (don't know this was the right/wrong approach) but it works.
But now most of the time these errors don't occur but they still occur, some time when page is posted back.
Please help us to remove this error.

Chrome JQuery Not Getting Height Correctly

I'm having a problem with http://taxlienagents.com/ and how it is displaying in Google Chrome. When I open the site in Google Chrome, the center Tab Area seems to cover the main text above it. If you take a look at http://img651.imageshack.us/img651/8869/taxliensite.jpg, you should be able to see what I am talking about versus when opening the site in FireFox. When I debug the site in Chrome the height is automatically set to 58px for some reason, however in FireFox it is set to 397px. I am using
setHeight : function (el) {
if (this.options.autoHeight)
this.$content_container.stop(true, true).animate({
height : this.getHeight(el)
}, this.options.animSpeed * 2 / 3, this.options.animation);
},
to get the height. I've gotten the site to be as XHTML 1.0 Transitional Compliant as I could, however I am not the original developer and I know that the site has some problems.
Well, first you should've mentioned that this is a Wordpress page :)
Check your WP version and make sure the plug-in want to use is actually supported from your version.
Otherwise this bit -
Unsafe JavaScript attempt to access frame with URL http://taxlienagents.com/ from frame with URL http://player.vimeo.com/video/32340130?title=0&byline=0&portrait=0&color=067fc0. Domains, protocols and ports must match.
causes your problems. But as I've said check your versions first.
If that's your own code, make sure it's in the right place, 'cause after 2 or 3 refreshes I can see your entire content. I mean the bits you can't.

IE9 throws exceptions when loading scripts in iframe. Why?

Precondition:
I have an aspx-page with iframe inside. This iframe points to the url handled by MVC on the same site (it's hybrid site, both standard ASP.NET and ASP.NET MVC). The resulting page rendered by MVC contains a lot of scripts references.
Problem:
IE9 throws an exception on every single script it load in iframe. These exceptions are similar to this one:
Error: 'Function' is undefined
That is, it says that the most basic things every window has is somehow absent. Once you clicked through all of these popups, the page just works as designed!
If I load a URL from <iframe /> src attribute in the browser directly, everything works as expected.
If I open the page in another browser (I tried Opera, Firefox), everything works as expected -- no errors.
So, what IE9 wants?
There is this msdn page about this bug (or feature).
You get these kinds of errors when you move the iframe element around in DOM. In such cases, IE 9 garbage collects the iframe (causing your undefined bug) and reloads it at another position.
In general, you should create the element, set its src attribute only once and then put it somewhere in the DOM tree once. It has nothing to do with the code which runs in the iframe itself.
I have encountered this same situation in the wild. Basic symptoms:
You load script code in an iframe
The script code runs early (from the head section or top of body)
IE complains about some missing native object
I found that it can often be prevented by delaying the execution of the script code until onload or DOMContentLoaded... Not much help I know but this is one of the most difficult IE scripting bugs I have ever encountered. I upped the score of your question, hope it will be found by others as well and we can get a more detailed answer.
Also see this question:
Error in Internet Explorer 9 (not earlier versions or other browsers) when including jQuery in an iframe
Placing the following script block at the very top of the iFrame html <head> seems to resolve the issue in my case. Basically, it forces the iframe to reload, which as some have pointed out, solves the issue. It seems relatively safe, because, without things like 'Object' and 'Date', javascript is essentially useless.
<script type="text/javascript">
if(typeof(Object)==="undefined"){
window.location.reload();
}
</script>
Try loading the javascript at the end after complete web page is loaded. I feel the script is executing even before the iframe is completely loaded.
for some suggestion of scripting in IE9 view the given link below
http://blogs.msdn.com/b/ie/archive/2010/06/25/enhanced-scripting-in-ie9-ecmascript-5-support-and-more.aspx
Further investigation revealed that the solution is to add the offending iframe to it's dom location BEFORE setting the 'src' attribute.
Once the 'src' has been set, changing location of the iframe within the DOM stack forces IE9 to garbage collect it.
Once 'src' has been set, iframe can be resized and changed via css positioning, but cannot change the relative location in the DOM stack.
Often times, plugins like dialogs and lightboxes will stuff an iframe with src already set into the dom, then append / prepend or whatever, triggering the GC to take place.
function waitForjQuery(){
if(typeof jQuery!='undefined'){
//Do yor stuff!
}
else{
setTimeout(function(){
waitForjQuery();
},500);
}
}
waitForjQuery();

Prevent selection being greyed out in iframe in Firefox without using contenteditable

In Firefox 3 and later (and probably older versions), selecting content within an iframe always seems to use the grey selection background colour used for a document that doesn't currently have focus, even if the iframe does have focus. The only exception I have been able to find is when the content within the iframe is editable. This is not the case in other browsers. Here's an example illustrating this:
http://jsfiddle.net/97Vjz/
This unfortunately prevents styling the selection within an iframe using the ::-moz-selection CSS pseudo-element because it only applies to non-grey selections:
http://jsfiddle.net/YYXSY/1/
My question is: is it possible to prevent an iframe's selection being grey in Firefox without using contenteditable / designMode?
UPDATE
This only seems to happen on dynamically written iframes: using a separate file and the src attribute solves the problem. However, I do need it to work with dynamically written iframes.
I just tried to reproduce the problem with a "real" page as iframe content and then it works like you want: blue colored selection! (FF 5.0)
see: http://jsfiddle.net/97Vjz/8/
It seems only generated content has this problem, so you could make a page (php/asp(x)) that generates the content for you to circumvent the problem.
Another solution to use javascript generated content is to load it with src="javascript:'<html />'" (actually this is Tim's own solution from the comments below.)
A simple example script: http://jsfiddle.net/97Vjz/9/
iframe.src='javascript:\'<html><body>' + content + '</body></html>\'';
There is a property of the iframe exposed in Firebug's DOM inspector contentDocument->designMode which is set to false for you iFrames. Forcing it to true through the DOM inspector enables the blue highlight you're after.
Hypothesis: It seems that for dynamically written iFrames, either a XUL Iframe is rendered or the Gecko engine doesn't honor the styles.
Short of submitting a bug, the only workaround I can see is to wrap our contents in a textarea and style it to make it 'invisible': http://jsfiddle.net/mrchief/YYXSY/19/

Categories