I have seen many examples on using javascript to resize a browser window, but for me they all fail to perform that function in IE. I include my code to see if anything is wrong with it that I just don't see. The code works great in FF but that is not used at my location.
I am no javaScript expert, but I am no slouch either. If I were new to javaScript I would be hating it. I'm sure it has something to do with IE but I cannot explain it.
Any help would be great.
CODE:
//window.sizeToContent();
window.resizeTo(700, 700);
I read in the docs that sizeToContent will not work in IE but resize should. It is an incredibly simple statement.
This works for me in Internet explorer 8
<html>
<head>
</head>
<body>
<h1>Resized</h1>
<script>
window.resizeTo(400,400);
</script>
</body>
I did some testing in IE9 beta (that's the only version of IE that I have on this machine), and it seems that window.resizeTo does not work on the initial page load. It does work if you refresh the page. Also, it does work if you delay its execution:
setTimeout(function() {
window.resizeTo(200, 200);
}, 2000);
(at least in IE9 beta)
The "working" example with IE is working only because there are no more tabs on the window.
If the windows has other tabs loaded, then it DOES NOT work. It's a security measure of IE8 and higher.
If you need to resize your window, you will need to open a new window. And for that, you will need to make the user click a button with the window.open onclick event, otherwise any popup blocker will block it.
You won't be able to resize the window reliably with JavaScript. It's not possible in IE 7 with tabbed browsing enabled. It's also potentially annoying for the user.
This seems to be IE only.
If your window is a "dialog" like:
window.showModalDialog(url,...)
I found this hacky way to make it the right size:
<script type="text/javascript">
//window.resizeTo(1000, 790); //Will not work if its a dialog
window.dialogWidth = '1000px';
window.dialogHeight = '790px';
</script>
Related
In our software, we have a page with a link that opens a page within the same site in a new tab using target='_blank'. When the user is done working on that newly opened page, they click a button and when the page refreshes, it calls the following code.
window.opener.location.href = window.opener.location.href; window.close();
This has worked fine for ages but within the last week or so stopped working in all browsers. I can't seem to find anything when I google it about a new security restriction being implemented that would cause this. Any idea what's going on and how to get it working again? I've tested the following code in chrome, firefox, edge and IE11. In all but IE11 window.opener is null. In IE it is not. Is there possibly a new security setting in browsers that would cause this?
<html>
<body>
click me
</body>
</html>
<html>
<body>
<script>
alert(window.opener === null);
</script>
</body>
</html>
I am not sure which version of chrome browser you tested your code on. To avoid "tab-napping" attacks, many browsers have started implementing noopener behavior by default for anchors that target _blank.
Chrome enabled noopener behavior in release 88.
Safari also enabled this in release 68.
I couldn't find any reference to IE 11 change. But it's worth trying adding rel="opener" in anchor tags with target=_blank
It is working good in internet exlporer but in chrome it works only if the user clicks on somewhere in the page i.e., works only when the user gives a click on that page at least once before pressing browsers back button. I want to make it work as same as in internet explorer.
here is my code:
<html>
<head>
<script>history.pushState(null,null,location.href);
window.onpopstate=function()
{
history.go(1);
}
</script>
<body>
<a location.href="home.php" rel="index,follow"></a>
</body>
</html>
I've stumbled on this question quite a lot and I had to achive the same thing
might not be the best solution, but I've made it to work in browsers IE, Explorer, Chrome, did not test Firefox tho, with this code:
<script type = "text/javascript" >
history.pushState(null, null, location.href);
history.back();
history.forward();
window.onpopstate = function () {
history.go(1);
};
</script>
The problem with Chrome is that it doesn't trigger onpopstate event unless you make browser action ( i.e. call history.back). Thats why I've added those to script. After adding only that made it work in Chrome but other browsers stopped adding history.forward fixed it and started to work on every browser mentioned.
Source if you want to know more or at least what helped me solve this
Hope it helps!
I have an alert box, and when I run that code in Firefox, no matter what program I have over firefox, firefox appears with the pop-up automatically over other programs open.
This however, does not work in Chrome.
What gives? Would this be a perference change or this there a line of code that says focus on this window.
I used
window.blur();
window.focus();
and that fixed my problem :)
The implementation of alert is browser specific. Unfortunately there is not line of javascript code to change this.
If you want to have customizable (and working the same in every browser) alert window, use jquery UI.
Note: It will be over the actual page, not over the (other) window.
Okay, this is by far the weirdest bug I have ever encountered. It's pretty straightforward though. If I load jQuery and then jQuery mobile dynamically in any version of Internet Explorer, the actual IE window minimizes. This happens in all versions of IE through IETester, however, if I run the full version in IE9, it kicks compatibility mode and for some reason doesn't minimize.
I've tried various ways of loading the scripts (commented in the example code), all resulting in the same behaviour.
Why is this happening? Is there a way around it?
http://jsfiddle.net/Xeon06/RCsuH/
This is a known issue in jQuery mobile. The offending line is jquery.mobile.navigation.js:913.
// Kill the keyboard.
// XXX_jblas: We need to stop crawling the entire document to kill focus. Instead,
// we should be tracking focus with a live() handler so we already have
// the element in hand at this point.
// Wrap this in a try/catch block since IE9 throw "Unspecified error" if document.activeElement
// is undefined when we are in an IFrame.
try {
$( document.activeElement || "" ).add( "input:focus, textarea:focus, select:focus" ).blur();
} catch(e) {}
There's the call to blur() that's sending IE windows to the back of the stack.
As a workaround, you can avoid this by placing the script tags physically in the <head> of the HTML.
<!DOCTYPE HTML>
<html>
<head>
<link rel="stylesheet" href="http://code.jquery.com/mobile/latest/jquery.mobile.css" />
<script src="http://code.jquery.com/jquery-1.6.2.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.js"></script>
...
Placing the script tags elsewhere in the document or inserting them via script triggers the bug.
This Fiddle demostrates the workaround in action. Note that this only works in a top-level document. If the document is in an <iframe>, the bug will still appear. Thus, if you open the JSFiddle editor in IE 7/8, it will still get sent to the back; but if you open just the rendered HTML, it will not.
My attempt at "fixing" it: http://jsfiddle.net/RCsuH/6/
#josh3736 was almost exactly right, somewhere in the code it is firing off a document.body.blur() which causes the minimization of the window.
My fix simply replaces that function with a no-op function. I was unable to get the script tags to fire an onload when they finished loading, so replacing the function (if necessary) is left up to you.
However all of this seems to be a bug in the jQuery Mobile library, and thus you should probably file a bug report with them. However, I'm not sure it will bother them too much that there is a bug on IE for a framework that is intended for mobile phones/tablets.
Note: This is horrible, horrible code that replaces native functions. If it is possible, don't use this.
I'm using window.print() from inside an iFrame. This works flawlessly in FF, but not so great in IE7. In IE7, it brings up the Print Dialog, however, the dialog itself is slow, choppy and unstable.
I'm having troubles understanding this problem, and any help would be greatly appreciated.
If I may add, the same thing happens when printing content of the same iFrame from outside of the iFrame in question. Further more, when clicking File->Print the Print Dialog appears to function normally.
Try using:
document.execCommand('print', false, null);
This appears to work in IE7, but you'll probably want to use a conditional and use window.print() for other browsers.