There is a legacy application built on Spring Webflow and RichFaces. Now, we have developed an application which is being rendered inside a modal window from the legacy app. The problem is, it works perfectly fine in Chrome, FF but IE. Some how the legacy application is rendered in IE7 document mode and when we open the new application in modal, it breaks everything. The CSS and JS are not working. I tried using the X-UA-Compatible tag and have valid <!DOCTYPE HTML> tag, still the issue persist.
Is there a way to solve this issue? How can we render the new application in Document Mode 10 or above?
If the site is in an iframe, then you would need to set the X-UA-Compatible meta tag on the parent page that contains the iframe.
If you can't do that, you might at least be able to get the legacy application to render in IE11 mode by turning off Compatibility View, if it's currently on.
I'm currently building a site where I'm using fonts.com to display a custom font for headers and subheaders. The font gets loaded via fonts.com javascript link and is then referenced in the CSS file as:
font-family: 'MyFontFromFontsDotCom';
It works fine and performs well. In IE8, however, the browser crashes after the font gets loaded (it never loads fully though) and the site. When I hit the "stop" button in the browser, the site gets rendered with the correct font.
I have a modernizr 2.6.2 running aswell which is referenced before the fonts.com javascript. When I remove the fonts.com javascript, the site runs just fine.
The fonts.com javascript reference is at the bottom of the body tag and the modernizr is at the head tag. I tried moving them around without any luck.
Has anyone experienced the same issue?
Thanks in advance.
I came across this issue when I was cross browser testing a site on IE 8. I fixed the issue by using the 'Non-javascript' (CSS) option.
You can get to this by going to the Manage Web Fonts section on fonts.com, selecting your project and then clicking the 'Publish Options' link.
In the window that pops up there is a tab for 'Option 2: Non-Javascript', this will give you a code snippet for CSS instead of Javascript. You should paste this in the head and then remove the Javascript snippet.
I know an answer was already accepted for this, and it is perfectly valid solution (using the CSS option instead of the Javascript option), but there is another possible solution if you do need the Javascript option (I like to have the -active classes added to my document).
It turns out there is a known issue with the fonts.com Javascript on IE8 when there are unclosed tags. So if you have a situation like:
<div><span>March 2014</div>
This will cause the fonts.com Javascript to cause troubles.
So find and fix unclosed tags with the W3C validator!
Issue
I have a strange issue with jQuery Mobile wrapped in Phonegap on iOS. My app consists of two pages, the second page being AJAX-loaded. On both pages I have images with a relative source like this
<img src="../images/myImage.png" />
On the first page, the image is displayed correctly. On the second page, the image is not found.
Explanation
I checked the src of both images with Weinre. It seems like Phonegap uses the data-url of the jQuery Mobile page div as prefix to the relative source. This works on page 1
file://path/to/app/html/../images/myImage.png
but not on page 2
file://path/to/app/html/page2../images/myImage.png
Why does Phonegap use the data-url on iOS?
Environment
What confuses me is that this problem only occurs in iOS Phonegap. It works fine in any browser and in Android Phonegap. It is a very basic "Hello World" like app with a standard jQuery Mobile page.
Solutions
I tried using the base tag, didn't work. I tried setting up the project again from scratch, didn't work. Any ideas?
I found the answer myself. Apparently jQuery Mobile identifies linked resources as external, if they don't have a file name suffix like ".html". My files were named without any suffixes.
So, I'm trying to find an answer to why this problem is happening; I've fixed the problem, but I want to know why it happened.
TL;DR
Google-provided conversion tracking code that injected an iframe using document.write suddenly caused the page to cease to execute in all versions of Internet Explorer, but was remedied by injecting the same iframe using a non-document.write method.
The Story:
Doubleclick is an advertising network that provides a JavaScript snippet to track conversions from ads.
The snippet they give looks like this:
<SCRIPT language="JavaScript">
var axel = Math.random()+"";
var a = axel * 10000000000000;
document.write('<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num='+ a + '?" WIDTH=10 HEIGHT=10 FRAMEBORDER=0></IFRAME>');
</SCRIPT>
<NOSCRIPT>
<IFRAME SRC="https://fls.doubleclick.net/activityi;src=143;type=donat01;cat=indir4;ord=1;num=1?"
WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>
</NOSCRIPT>
Now, I know that, for all sorts of reasons, document.write is hazardous and should be avoided. But, Google is giving me this code, so, I figured I could trust it.
It suddenly started breaking all of our pages for all users using Internet Explorer. As in, the page would stop rendering entirely once it hit the document.write. This was crazy: One of the largest third party advertisers on the internet had given me JavaScript that had LITERALLY broken my purchase pages for 25% of my traffic!
As triage, I quickly substituted in the same code using the injection technique found in Google Analytics:
var iframe = document.createElement('iframe');
iframe.src = //the URL;
iframe.width = 0;
iframe.height = 0;
iframe.frameborder = 0;
var ref = document.getElementsByTagName('script')[0];
ref.parentNode.insertBefore(iframe, ref);
This resolved the problem, without actually explaining:
Why does a nearly empty iframe, injected using document.write, break Internet Explorer, but this method above doesn't?
I've solved the problem; it turns out that it had nothing to do with the contents of the <iframe>.
It turns out the page is served by a framework that began using a backend DOM parser that, for reasons likely related to the presence of </ within a <script> tag within the document.write, completely removes the </iframe> closing tag from the generated page, even though it preserves it in the backend. (It's probably trying to enforce ETAGO rules).
The reason I was able to reproduce it was because I was copying the generated document.write code, not the original code, and never noticed the missing </iframe>. (And my "functioning" document.write code didn't have the stripped out </iframe> tag, leading me to believe that the problem was the contents of the iframe.)
As a result, browsers parsed an unclosed <iframe> tag on the page, which Internet Explorer didn't know how to handle, and died part way through the parsing of the iframe (I'm still not totally sure why).
document.write() blocks further page rendering until it finishes. I assume that the remote script was taking a while to load, and thus blocking the rest of the page from loading.
I also assume that Math.Random() function doesn't help matters.
Also...Google's tracking codes scare me...they tend to be ugly hacks of javascript.
There is 2 reasons why the first method should be slow.
document.write() blocks until it is actually performed
the window’s onload event doesn’t fire until all its iframes, and all the resources in these iframes, have fully loaded
Your solution works because the iframe it creates does not request the remote url until after the onload event. Having a set timeout on the first code, you would also get the page to load, then the request to the remote url to fire.
As to why the change of code broke the site, I can not seem to find any speed differences transferring between the two. Maybe it seemed faster because it was cached.
I don't know about the structure of your site, but normally the first script tag is in the <head>. An iframe in the <head> wouldn't be rendered. I'll wager if you did document.body.getElementsByTagName('script')[0] you would probably have similar issues to the one you described above.
Seems you're having a similar problem that I had several months back. The document.write triggers, and overwrites the page. Just use the iframe directly, and everything should be kosher.
I tried replicating your issue but couldn't on IE9.
Either I don't have the right test setup or it seems IE prior to IE 9 had some bug. Firefox had a simialr bug: https://bugzilla.mozilla.org/show_bug.cgi?id=293633
Maybe its a combination of unclosed iframe and something inside the page that's being rendered.
I'm looking for a way to embed an SWF into a page and get around the Internet Explorer security issue (where it requires an extra click to "activate" the flash file).
I've got my code working with swfobject, but I'm using this in an embedded widget context (eg a clickable banner ad) so I am really trying to keep my file size down, and swfobject adds about 10k worth of minified Javascript that just feels like more than I need
I just need basic flash rendering, I'm not really that worried about Flash version detection (I'm using an old enough version of Flash for the SWF) though a fallback solution if flash is not available would be nice.
Finally, this has to be something that can work entirely from a single Javascript file included somewhere in the BODY tag of the containing page. (The reason I say this is because I had some issues even with the swfobject version when I was document.write'ing a SCRIPT tag for the swfobject.js into the BODY of the page instead of the HEAD).
I hope that makes sense, I can clarify if needed.
Thanks in advance!!
"Click to activate" is no longer an issue, see this note.