Hello I getting not visible IFrame in IE I try print it, but IE return error what focus() method not identified. Why I get it? I remember that some days ago it wored
var iFrame = document.frames["printIfram"]; //document.frames.printIframe;
iFrame.focus();
iFrame.print();
Put a print function inside the Iframe to make it print itself on load:
At the bottom of the page, just use window.print()
You missed the e on the end of printIframe.
If that's just a typo, try iFrame.contentWindow.focus().
i got the same problem in ie8 and i thought it's a bug of ie
i tryed the accepted answer ,it haven't work yet;
nomatter where is the window.print(),it always print the parent page
so ,i give up the iframe,just open a new tab to print
have you got it work?
Related
I have a custom date picker popup that isn't working in IE sometimes. It works in Chrome and Edge fine.
The code looks something like this:
<frameset>
<frame>Buttons for next/prev month/year</frame>
<frame>This is the actual calendar that gets redrawn when the above buttons are used
1 //there's a different anchor tag for each day of the month
</frame>
<frameset>
So here's where it gets kind of weird. We have two networks, call them old and new. Old has probably a lot of undocumented global policy changes and new is probably close to the gov standard. This works on any browser on the old network, but not IE (11) on the new network. It works in Edge though. Additionally, if the top frame buttons are used to pick the next/prev month, or just the "Today" button, then all of the bottom frame anchor links work normally. There are no console errors/warnings, nothing in the network monitor showing a request returned an error code, the clicks just don't register. I put a breakpoint inside customFunction() and it won't break when the links don't work, but it will break if the link will work.
The only other thing that seems odd to me is that the code for the whole popup looks something like:
str = "<frameset><frame name='topFrame' " +
"src='javascript:parent.opener.drawTop'></frame><frame name='bottomFrame' "+
"src='javascript:parent.opener.drawBottom'><frame</frameset>"
document.write(str);
I did look to check and the code that redraws the bottom frame when the prev/next/etc buttons are used is the same function that gets called during the first load.
However, what seems odd about this is that on the first load the DOM inspector shows everything (top frame, bottom frame including all the individual numbers for each day of the month, etc), but the Debugger (F12 tools) doesn't show the code loaded with the document.write(str); line. To be able to see that code and set break points I have to use the prev/next buttons and then an additional .html file shows up in Debugger which has the constructed HTML that matches the DOM.
try this:
1)
1
2)
1
3)
1
4) check your code. Maybe your frame has attribute 'sandbox'. This attribute can block javascript. Example:
<iframe src="URL" sandbox>
Aside from the great suggestions by Nutscracker, I've also had my share of vague problems with document.write and event handlers not attaching in IE. The problem commented on by ConnorsFan could be the cause here, but you could also try:
document.body.innerHTML = '<frameset><frame name="topFrame" ' +
'src="javascript:parent.opener.drawTop"></frame><frame name="bottomFrame" '+
'src="javascript:parent.opener.drawBottom"><frame></frameset>'
You might also want to check this code is actually being called, maybe the real working popup is loaded from somewhere else by the prev/next buttons and this is just some leftover stuff.
If your onclick function returns false the default browser behaviour is cancelled. As such:
<a href='http://www.google.com' onclick='return check()'>check</a>
<script type='text/javascript'>
function check()
{
return false;
}
This means that you can set your JavaScript function as an onclick event, and just have the anchor tag linking back to the page you are on - as it won't redirect you when you click it but needs a href attribute.
Yes, as the name suggests, I am getting two print dialogs on Chrome latest and FF latest.
The code I'm using is:
var $printButton = $('#print_button');
if ($printButton) {
$printButton.on('click', function () {
window.print();
})
}
The second dialog only opens when I have actioned the first dialog (print or cancel), if that helps.
EDIT:
After narrowing it down to an issue with my callback, I put a console.log('hello'); in the script and found that it was calling twice on refresh.
My script file was being included twice somewhere on the page. Thank you legacy code :)
Thanks for the advice everyone.
I currently have a form set up with 5 radio options. I have a switch statement depending on the option you pick and that determines where the email is going to go.
Inside my switch, I have this piece of code.
window.open("mailto:"+emailTo+'?cc='+emailCC+'&subject='+emailSub+'&body='+emailBody);
It all works fine when it opens up my email client with all of the content however it also opens a blank page in the browser.
Is there another way to achieve this or prevent a blank window from opening but still make it as if you clicked on the href:mailto ?
Instead of:
window.open("mailto:"+emailTo+'?cc='+emailCC+'&subject='+emailSub+'&body='+emailBody);
You can try:
location.href = "mailto:"+emailTo+'?cc='+emailCC+'&subject='+emailSub+'&body='+emailBody;
The second argument in window.open is the target.
window.open('mailto:'+emailTo+'?cc='+emailCC+'&subject='+emailSub+'&body='+emailBody, '_self'); should do the trick.
Location.href doesn't seem to work in chrome.
I do it like this:
x=window.open("mailstring");
x.close();
Works perfect for me.
After your "window.open" statement, try running an "if statement" to check and see if a new window was opened so that it will close.
if (win && win.open && !win.closed)
{
win.close();
}
This will happen very fast so the users might notice that a window opened and closed before the email application opened.
I'm building a CMS application which I'm debugging now for IE. But things happen I cant comprehend.
First I have a div with the content of a page. I extract the content of the div and with javascript I create an iFrame and append that to the div. This is for making the WYSIWYG-editor. Then when I want to add the content to the iFrame the problems start. IE can't access the iFrame's body for some reason. I can alert the iFrame's document, which gives me [object Document] or [object HTMLDocument], but when I then alert the body I get null.
I use this function for getting the document as part of a javascript object:
iframedoc: function(aID) {
if (document.getElementById(aID).contentDocument){
return document.getElementById(aID).contentDocument;
} else {
var iFrame = document.getElementById(aID);
return iFrame.contentWindow.document;
}
},
and this is where I call it for the first time:
tas[i].innerHTML = "";
tas[i].appendChild(ta_edit_functions);
tas[i].appendChild(ta_edit);
tas[i].appendChild(ta_result);
alert(ta.iframedoc(ta_edit_id));
ta.iframedoc(ta_edit_id).body.innerHTML = ta_edit_content;
ta.iframedoc(ta_edit_id).designMode = 'on';
Here I empty the div, append a div containing the WYSIWYG-functions, the iFrame and the textarea for eventually submitting the form.
I'm testing in IE 8 and 9. Weirdest thing is that when I put an alert before first calling iframedoc in IE 8 I suddenly do get the body.
I would be really grateful if someone could at least point me in the right direction. I really don't have a clue what's happening.
I'm testing in IE 8 and 9. Weirdest thing is that when I put an alert before first calling iframedoc in IE 8 I suddenly do get the body.
That sounds as though you're going too fast for the browser -- the iframe is probably just not fully loaded yet when you try messing with it, so adding in an alert gives it the extra time it needs. Try deferring some of your code using an onload event on the iframe element.
Eventually my solution was using a interval function checking if the body of the iFrame is available.
But with those errors gone I found out that in IE8 turning on designmode for the iFrame removed all the content of it. So I ended up just using a contenteditable div..
Having an issue here that I have tried everything I can think of but cant get it to work. I have a page with a link that creates a cfwindow like so
function create_window(ID){
var config = new Object();
config.modal=true;
config.center=true;
config.height=775;
config.width=700;
config.resizable=false;
config.closable=false;
config.draggable=false;
config.refreshonshow=true;
ColdFusion.Window.create('newWindow','Window Title', '/source/url'+ID, config)
The window is created and the URL has the ID parsed to it that is used for displaying the correct item in the window. This all works fine.
The problem is when I try and close the window and open a new window with a different item being displayed, the URL is not changed. I realise that this is because the window is being hidden, and not destroyed, and therefore it is the same window being opened. So I have created an onHide event handler to destroy the window like so.
function showItemDetails(){
var ID=document.getElementById("sList").value
create_window(ID);
ColdFusion.Window.onHide('newWindow', refreshList);
}
function refreshList(){
ColdFusion.bindHandlerCache['sList'].call();
ColdFusion.Window.destroy('newWindow',true);
}
Now when I close the window Firebug is returning the error "ColdFusion.Window.destroy is not a function" (In IE the error is "Object doesn't support this property or method"). I have made sure we are running the latest version of ColdFusion 8.01 on the server (as I know that .destroy wasnt added until 8.01) and have applied the latest hotfixes to the server as well.
Any ideas?
Unfortunately, ColdFusion.Window.destroy() doesn't really destroy is a known bug. I'm not sure they've fixed it in CF9 or not, but it was definitely left unfixed in CF8.
Use ColdFusion.navigate() as a workaround. Instead of destroying the window, reuse the same window and navigate it to some other URL.
EDIT: Try this instead:
function refreshList(){
ColdFusion.bindHandlerCache['sList'].call();
var newWindow = ColdFusion.Window.getWindowObject('newWindow');
newWindow.close();
}
I think this is closer, per Adobe's docs...