I'm working on some code I inherited that uses jQuery to generate some DIV blocks containing text and images. It generates the blocks, appends them to the page, then calls outerHeight() on the blocks' inner text elements and uses those heights to calculate how big the accompanying images should be.
In all browsers except Safari, things work fine.
In Safari, when outerHeight() is called, sometimes the just-appended elements aren't fully rendered, so the measurement returned is not accurate, and the resulting page doesn't look right. I can see this in the debugger - my breakpoint is hit just after an incorrect outerHeight() is saved, after a second or two I see the rendering catch up, and calling outerHeight() again gives the correct value.
I've tried to serialize this sequence more explicitly using setTimeout and to call outerHeight() a bit later in the code. This made the issue happen less frequently, but it still happens sometimes.
I feel like this has to be a common pattern - get the dimensions of just-appended elements. Has anyone dealt with this before?
Experimenting with various delays, I saw that most of the time, Safari would finish rendering the appended elements after no more than 250ms or so. To deal with this issue, I use setTimeout to run a function after a delay to check whether the previously measured heights match the current ones in the DOM. If they don't, then I know that the rendering has changed, and I re-do the layout of these elements.
Related
Inputs like textboxes and checkboxes work extremely slow in the bootstrap modals. When user types some text, cursor is moving but the letters appear only in several seconds. The same behavior with checkboxes, checked/unchecked state changes only in several seconds.
Can be reproduced only IE8 and Vista machine.
does anybody has an idea why it happens.
here is a video with an example.
you can try it here in the login dialog.
not 100% why, but ie8 has extreme problems rendering sites using position:fixed in their layout process. on random element(s), position:fixed shouldn't be too much of a problem, but typically when this issue arises it is because it is being applied to elements that are used as wrappers or containers, that usually are full of content.
for whatever reason(s), ie8 has a mighty difficult time rendering here...its best described as delayed response(s), where the user isn't sure if they actually interacted with the site, because nothing happens after their action(s).
changing fixed to absolute is the best answer in these cases, most of the time. i know there are situations where this will not apply, but everytime i've faced this issue, the element(s) had wrapper element(s) with position:relative set, and swapping out absolute for fixed could not have been easier.
ideally for me, is to serve up the different setting in conditional comments, which also is quite useful just in case changing from fixed to absolute breaks something(s)...you can target them in ie(s) and ie(s) alone with the cc's.
I've implemented the solution described in this previous post Resizing an iframe based on content and it's almost working great, but not quite.
The problem I'm getting is that sometimes it calculates the height correctly, sometimes it calculates it way too short and the content gets chopped off.
I'm looking for some suggestions as to what may cause this, because everyone else seems to have success. It seems to me that if the height is calculated incorrectly, then perhaps the calculation is happening before all the data has loaded into the iFrame from the external source. But that is a guess, and I am by no means a JS expert.
Is there something I can do to ensure that the calculation is done after the external page has finished loading?
It is pretty much impossible to get the height calculated right. I have played around with it for quite some time. One of the things I have experienced is, if you have a form inside the iframe and there are some error handling events in the form. Lets say there is a table in the form with hidden rows etc. Then when the errors appear the table gets "higher" as the rows start appearing, so the height range is now different again. Whenever there is a post back done inside the iframe one can not control the height. I have tried about every solution posted out there and could not get it calculated right. I had to estimate the "highest" height and hard code it to be that height.
I expect the issue is that you need to detect when the content in your iFrame is changing and then resize your iFrame again. In modern browsers you can use mutationObserver to do this, but it doesn't work in IE10 downwards, so you have to use failbacks to workaround this.
I wrote a small library that looks after all these issue and will keep an iFrame sized to it's content. Work's in modern browsers and IE8 upwards.
https://github.com/davidjbradshaw/iframe-resizer
I have a function that positions an element in my Firefox extension, and I need that function to be called whenever an event causes the window/chrome layout to change.
Events would be:
When a new window is created, after the chrome is rendered.*
When a window is re-sized.
Any other event that might cause the chrome layout to change size or shape?
(*) Right now, the function runs when a new window is created using:
window.addEventListener("load",myfunction);
But this runs before the chrome is rendered, and element sizes have wonky values. I need it to run after Firefox determines the actual size and placement of the chrome elements.
What are the events I would need to bind to, and how do I bind them?
I was in a similar situation, and didn't really find a good solution. However, the non-standard MozAfterPaint event may help, but comes with a somewhat sizable performance penalty however (so make sure you remove it once you don't need it anymore).
The resize event should do the trick.
There are tons of things that may cause things to change. New CSS/Images loading, toolbar customization, etc. 1. and 2. should cover most (all?), however.
The devtools layoutview ("Box Model") seems to use MozAfterPaint as well.
If possible, you should try to avoid having to calculate sizes yourself, however, by making use of the XUL/HTML flexbox model and CSS without fixed sizes (or min/max sizes only).
I've got a strange error with IE8 and postcode lookups. It may not be postcode lookups as such that's causing it - just an AJAX call that modifies a select. I've set up a test page here. If you click on Find Address, and then double click (quite quickly) on one of the addresses that is within the boundary of the red-bordered div, you see the below bug in IE8.
Note: I'm finding it inconsistent to reproduce the bug, but if you scroll the list of addresses right to the bottom and then double click fast on Holly Cottage it should reproduce the bug.
If anyone can shed on light on this quirky behaviour it'd be much appreciated. Is this an IE8 bug?
I've found the problem - browsers do not like having javascript:void() set for the href attribute. If you want to have a working anchor whose default action is canceled, then use # for the href attribute, then have the event handler for that anchor return false to cancel the browser's default action.
Erm... right... sorry for my eagerness to post an answer and not double check that the problem was properly solved.
I'm finding it difficult to find the problem. I'm only going to hazard a guess here: the two effects running and ending at the same time confuses IE8, causing the div to be set to a height of 1px. This of course assumes a bug in the jQuery implementation of the effect queue, which I definitely cannot vouch for. It's just my theory at the moment - my unfamiliarity with IE developer toolbar prevents me from investigating further.
It's a problem with You running animations I suppose.
Your asynchronous action triggers some sliding animations.
First:
Try logging endings of all animations (put a callback function in the slide* call and log some text to console.) to see if they run in correct order - I suppose they don't and that's the problem.
Second:
Try adding .stop() before every asynchronously triggered animation so that it breaks other animations working at the same time.
Third:
If the above didn't help try this for every animation:
if($(this).data('running')==0){
$(this).data('running',1).slideUp(function(){$(this).data('running',0)});
}else{ /*call with timeout or ignore...*/ }
It's a basic semaphore on an element.
OR
You can use .animate and animation queues in jQuery properly, but it'd be a bit of an overkill for this case (I think).
My first reaction is it may be a CSS issue. If I find the default value, and click the 'Find Address' link one time, I see a similar (though not identical) layout problem. The height on each section looks collapsed, as if the floating sections aren't picking up the correct content height. If I incrementally specify a height on each contentRow or switch the display from block-none-block on pcodeLookupAddressEdit_risk_address, the formatting is corrected.
I don't know the specific cause, but, you may want to check the CSS and the show/hide behavior on the slide.
On a dynamic site of mine I faced a problem that consists in the following:
In Internet Explorer 6 after changing the size of the div element with the help of JavaScript, its child elements that are 100% in height do not refresh right away (ie. do not stretch to their new size) but only when the parent div is clicked. It seems to me that the document needs some update. I'd like to ask if there is sort of a command (like that in Flash) that updates the document after some dynamic changes get happened? In brief, how can this problem be settled?
Requiring reflow in IE6 is a very common problem with a massive CSS/JS base. Usually all you have to do is change a parameter on the element that requires a reflow, like, for example, set display:none and then back. This will cause browser to reflow objects in and around current object. Most of the time you will have to do it from JavaScript. If you don't want to do display, try changing height/width or add/remove flow or clear parameters. They all will cause reflows of the page.
However, most of the time if you are running into reflow issues in IE6 it usually means that either you have way too much CSS on the page, or you are using CSS for things it shouldn't be used for (like laying out elements on the page that in HTML go in a wrong order, i.e. element1, element2, element3 in HTML; element2, element1, element3 in display). I would suggest cleaning up your CSS and most of the times, reflow problems will go away.
If you have to click on it to refresh, then why no try to simulate a click, after the size update. Simulating mouse clicks in JavaScript
I know that I have been burned (more than once unfortunately) to have returned invalid xml for an ajax response. IE in particular is very non-forgiving in this respect. It might be worth validating the response just to be sure. In some of my cases, the bad XML caused JS to fail and not "seem to work".