First, I get the window width and minus something then assign it to a variable,
Second, I resize the window and want to get the value that is current window width minus something
but I get wrong value, it will alert two value one is right and another is wrong,I do not know why and how to fix it, help me, thx
my html code is
<p class="test">click me get value</p>
js is
(function(){
test();
$(window).resize(function(){
test();
});
}());
function test() {
var t = $(window).width()-74;
alert('one ' +t);
$(document).on('click', '.test',{t: t}, get);
}
function get(event) {
var l = event.data.t
alert('two ' +l)
}
the fiddle version is
http://jsfiddle.net/dxcqcv/xetbhwpv/1/
I am not sure what are the values you are expecting to get, but take a look at the resize function documentation on jquery api:
http://api.jquery.com/resize/
Code in a resize handler should never rely on the number of times the handler is called. Depending on implementation, resize events can be sent continuously as the resizing is in progress (the typical behavior in Internet Explorer and WebKit-based browsers such as Safari and Chrome), or only once at the end of the resize operation (the typical behavior in some other browsers such as Opera).
As you can see, some browsers will call resize only at the end of the resizing, but some other will keep calling your function on the process of resizing. This means you will get different values from your call when you are not resizing and while in a resizing operation.
I made some changes to your code in order to become cleaner. Please take a look at this jsfiddle using the developer console (press F12 on browsers):
http://jsfiddle.net/xetbhwpv/7/
$(document).ready(function(){
test();
$(window).resize(function(){
test();
});
});
function test() {
var t = $(window).width() - 74;
console.log('one ' + t);
$('.test').off('click');
$('.test').on('click', {t: t}, getInfo);
}
function getInfo(event) {
var l = event.data.t
console.log('two ' +l)
}
As you can see now, the last two XX messages are equal to the last resize messages.
Related
I'm hoping someone can explain to me this odd behavior I'm seeing with window.scrollTo.
This doesn't work.
document.addEventListener('DOMContentLoaded', function() {
console.log('window.scrollY = ', window.scrollY);
window.scrollTo(0, 200)
console.log('window.scrollY = ', window.scrollY);
});
... well it does work, sort of ...
It works for the initial page load, but not refreshes (cmd + shift + r)...
The console output is:
window.scrollY = 0
window.scrollY = 200
So in that sense its working... except the page isn't scrolled, and when you type window.scrollY into the dev console it does indeed show 0.
So it would appear that the scroll is being set too early?
Where I get real confused is here:
var delay_ms = 0;
document.addEventListener('DOMContentLoaded', function() {
setTimeout(function() {
window.scrollTo(0, 200);
}, delay_ms);
});
SOMEHOW THAT WORKS, but not consistently.
However...
var delay_ms = 10;
Increasing the delay, even by only 10ms, improves the consistently dramatically! To the point where it hasn't failed on me yet.
At first I thought maybe DOMContentLoaded was simply too early for height to be properly evaluated, so I switched the event I was listening for to:
window.addEventListener('load', function() { /* ... */ });
According to the MDN Docs for .onload
The load event fires at the end of the document loading process. At this point, all of the objects in the document are in the DOM, and all the images, scripts, links and sub-frames have finished loading.
So I can't imagine what would be setting the scroll to 0, after I'm setting it to 200...
Does anyone have any insight into what is happening with this timing?
Covering my bases
Yes there is space to scroll.
Here's a gist with some full reproduction code.
I'm on a mac, using chrome.
I'm writing a website with a canvas in it. The website has a script that runs successfully on every refresh except for a line at the end. When the script ends with:
document.body.onresize = function() {viewport.resizeCanvas()}
"document.body.onresize" is unchanged. (I double-checked in Chrome's javascript console: Entering "document.body.onresize" returns "undefined".)
However, when the script ends with:
document.body.onresize = function() {viewport.resizeCanvas()}
console.log(document.body.onresize)
"document.body.onresize" does change. The function works exactly as it should.
I can't explain why these two functionally identical pieces of code have different results. Can anyone help?
Edit: As far as I can tell, "document.body" is referring to the correct "document.body". When I call console.log(document.body) just before I assign document.body.onresize, the correct HTML is printed.
Edit 2: A solution (sort of)
When I substituted "window" for "document" the viewport's "resizeCanvas" function was called without fail every time I resized the window.
Why does "window" work while "document" only works if you call "console.log" first? Not a clue.
Resize events: no go
Most browsers don't support resize events on anything other than the window object. According to this page, only Opera supported detecting resizing documents. You can use the test page to quickly test it in multiple browsers. Another source that mentions a resize event on the body element specifically also notes that it doesn't work. If we look at these bug reports for Internet Explorer, we find out that having a resize event fire on arbitrary elements was an Internet Explorer-only feature, since removed.
Object.observe: maybe in the future
A more general method of figuring out changes to properties has been proposed and will most likely be implemented cross-browser: Object.observe(). You can observe any property for changes and run a function when that happens. This way, you can observe the element and when any property changes, such as clientWidth or clientHeight, you will get notified. It currently works only in Chrome with the experimental Javascript flag turned on. Plus, it is buggy. I could only get Chrome to notify me about properties that were changed inside Javascript, not properties that were changed by the browser. Experimental stuff; may or may not work in the future.
Current solution
Currently, you will have to do dirty checking: assign the value of the property that you want to watch to a variable and then check whether it has changed every 100 ms. For example, if you have the following HTML on a page:
<span id="editableSpan" contentEditable>Change me!</span>
And this script:
window.onload = function() {
function watch(obj, prop, func) {
var oldVal = null;
setInterval(function() {
var newVal = obj[prop];
if(oldVal != newVal) {
var oldValArg = oldVal;
oldVal = newVal;
func(newVal, oldValArg);
}
}, 100);
}
var span = document.querySelector('#editableSpan');
// add a watch on the offsetWidth property of the span element
watch(span, "offsetWidth", function(newVal, oldVal) {
console.log("width changed", oldVal, newVal);
});
}
This works similarly to Object.observe and for example the watch function in the AngularJS framework. It's not perfect, because with many such checks you will have a lot of code running every 100 ms. Additionally any action will be delayed 100 ms. You could possibly improve on this by using requestAnimationFrame instead of setInterval. That way, an update will be noticed whenever the browser redraws your webpage.
What you can do is that if you know for certain what particular action triggers a resize on your element that doesn't resize the full window you can trigger a resize event so your browser recalculate all of the divs (if by the case the browser is not triggering the event correctly).
With Jquery:
$(window).trigger('resize');
In the other hand, if you have an action that resizes an element you can always hold from that action to handle other following logic.
<script>
function body_OnResize() {
alert('resize');
}
</script>
<body onresize="body_OnResize()"></body>
Inside the Javascript console, if I execute:
m = window.open(location.origin);
m.resizeTo(400, 400);
The window will resize, but if I just execute:
window.resizeTo(400, 400);
then nothing happens. I understand the reason for this behavior. How can I detect situations where window.resizeTo will do nothing?
Approach 1:
You can use the window.opener property. If it's null, then you did not open that window and thus cannot resize it.
window.parent is intended more for iframes and the like.
Such as:
if (m.opener) {
m.resizeTo(400, 400);
} else {
// You did not create the window, and will not be able to resize it.
}
Approach 2:
ajp15243 brings up a good point, so one thing you could do is listen to the resize event and see if your resizeTo worked:
var resizeFired = false;
...
var triggeredResize = function() {
resizeFired = true;
m.removeEventListener('resize', triggeredResize);
}
m.addEventListener('resize', triggeredResize, true);
m.resizeTo(400, 400);
if (resizeFired) {
// Your resize worked.
}
I haven't been able to fully test this, but it's one potential approach nonetheless. For IE8 and below you may need to use attachEvent instead. Also as #Wesabi noted, the resize may fire for other events (and may fire if the user is resizing the window as the listener as attached), so it's best to execute this is the shortest time span possible.
Approach 3:
Another approach would be to call m.resizeTo(400, 400) and then check the window size to see if the current size is equal to what you set it to:
m.resizeTo(400, 400);
if (w.outerWidth != 400 && w.outerHeight != 400) {
// Your resize didn't work
}
The easiest thing to do would be checking if the window has a parent. if !window.parent, it means it's the main window which cannot be resized with JS, else you have your resize case.
Edit: Igor posted it before I found it: you want m.opener() not window.parent
MDN is a great JavaScript resource: https://developer.mozilla.org/en-US/docs/Web/API/Window.resizeTo
Since Firefox 7, it's no longer possible for a web site to change the default size of a window in a browser, according to the following rules:
You can't resize a window or tab that wasn’t created by window.open.
You can't resize a window or tab when it’s in a window with more than one tab.
SO, you need to detect if you are a child window:
https://developer.mozilla.org/en-US/docs/Web/API/Window.opener
if (window.opener) {
console.log('I can be resized');
} else {
console.log('I cannot be resized');
}
I discovered a problem that seems to reproduce always when opening a piece of html and javascript in IE8.
<html>
<body>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js"></script>
<script>
$(document).ready(function(){
$(window).resize(function() {
console.log('Handler for .resize() called');
});
});
</script>
<div id="log">
</div>
</body>
</html>
Loading this file in IE8 and opening Developer Tools will show that the log message is printed continuously after one resize of the browser window.
Does anyone has an idea why? This is not happening in IE7 or IE9, nor in other browsers (or at least their latest versions).
UPDATE
One solution to prevent the continuos trigger of resize() is to add handler on document.body.onresize if the browser is IE8.
var ieVersion = getInternetExplorerVersion();
if (ieVersion == 8) {
document.body.onresize = function () {
};
}
else {
$(window).resize(function () {
});
}
But this does not answer my question: is the continuous firing of resize() a bug in IE8?
If "show window contents while dragging" is switched on, you will be inundated with resize events. I guess you're testing IE8 on a separate Windows machine which has this effect enabled (Display Properties -> Appearance -> Effects...).
To counteract this, you can wrap & trap the resize events to tame them: http://paulirish.com/demo/resize
This article says Chrome, Safari & Opera suffer from this too.
I only see the issue you are describing if an element on the page is resized (as described in this question). Your example doesn't work for me, but I assume for you it is appending the console message in the log div that you have there, which means that it is resizing the div and triggering the window resize event.
The answer that Lee gave is correct, but the method in the link didn't work for me. Here's what I did:
var handleResize = function(){
$(window).one("resize", function() {
console.log('Handler for .resize() called');
setTimeout("handleResize()",100);
});
}
handleResize();
This way, the handler is unbound as soon as it fires, and is only re-bound after you've finished all your actions that might re-trigger a page resize. I threw in a setTimeout to provide additional throttling. Increase the value in case your scripts need more time.
I assigned a timeout to my window.resize handler so that I wouldn't call my sizable amount resize code every time the resize event fires. My code looks like this:
<script>
function init() {
var hasTimedOut = false;
var resizeHandler = function() {
// do stuff
return false;
};
window.onresize = function() {
if (hasTimedOut !== false) {
clearTimeout(hasTimedOut);
}
hasTimedOut = setTimeout(resizeHandler, 100); // 100 milliseconds
};
}
</script>
<body onload="init();">
...
etc...
In IE7 (and possibly other versions) it appears that when you do this the resize event will constantly fire. More accurately, it will fire after every timeout duration -- 100 milliseconds in this case.
Any ideas why or how to stop this behavior? I'd really rather not call my resize code for every resize event that fires in a single resizing, but this is worse.
In your //do stuff code, do you manipulate any of the top,left,width,height,border,margin or padding properties?
You may unintentionally be triggering recursion which unintentionally triggers recursion which unintentionally triggers recursion...
How to fix the resize event in IE
also, see the answer for "scunliffe" "In your ... properties?
IE does indeed constantly fire its resize event while resizing is taking place (which you must know, as you are already implementing a timeout for a fix).
I am able to replicate the results you are seeing, using your code, on my test page.
However, the problem goes away if I increase the timeout to 1000 instead of 100. You may want to try with different wait values to see what works for you.
Here is the test page I used: it has a nicely dynamic wait period already set up for you to play with.
I stumbled on the same problem, but solved it differenly, and I think it's more elegant than making a timeout....
The context: I have an iframed page, loaded inside the parent page, and the iframe must notify the parent when its size changes, so the parent can resize the iframe accordingly - achieving dynamic resizing of an iframe.
So, in the iframed HTML document, I tried to register a callback on the body tag. First, on the onchange - it didn't work. Then on resize - it did work, but kept firing constantly. (Later on I found the cause - it was apparently a bug in Firefox, which tried to widen my page to infinity). I tried the ResizeObserver - for no avail, the same thing happened.
The solution I implemented was this:
<body onload="docResizePipe()">
<script>
var v = 0;
const docResizeObserver = new ResizeObserver(() => {
docResizePipe();
});
docResizeObserver.observe(document.querySelector("body"));
function docResizePipe() {
v += 1;
if (v > 5) {
return;
}
var w = document.body.scrollWidth;
var h = document.body.scrollHeight;
window.parent.postMessage([w,h], "*");
}
setInterval(function() {
v -= 1;
if (v < 0) {
v = 0;
}
}, 300);
</script>
So how it works: each time the callback fires, we increment a variable v; once in every 300 ms, we decrement it; if it's too big, the the firing is blocked.
The big advantage of this over the timeout-based solution, is that it introduces to lag for a user experience, and also clear in how exactly it does block the recursion. (Well, actually not )))