In IE7, this code isn't working properly:
myJqObj.css("height", DEFAULT_HEIGHT);
When it runs, it seems to set the height of myJqObj to 0; However, if I query the height immediately after setting it, everything works fine:
myJqObj.css("height", DEFAULT_HEIGHT);
myJqObj.height();
This also works:
myJqObj.css("height", DEFAULT_HEIGHT);
myJqObj.width();
I'm sure if you run the previous code on its own, things will work fine. This is all happening in the midst of some fairly complex page building. There's obviously something in my js environment that's causing a bug. Anyone seen anything like this before? Any ideas where to start looking?
I would check specificity. Have you verified your "myJqObj" object is specific enough for IE7?
When I set CSS that takes in FireFox and not in IE7, it's usually because I've set CSS for an element such as the <div id="mydiv"><p> element, and my <div id="mydiv"><p class="myclass"> height definition is being overridden by the first definition.
You might be looking in the wrong place.
Have you set myJqObj to float in the CSS? If so the height will actually be 0 since a floated element collapses.
Same problem setting height in IE7
Solved it too by just querying the height after setting it.
Is this a bug???
Related
In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.
Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.
Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.
i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.
Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>
#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.
It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.
This is the closest I've seen:
Changing font-size with jQuery css() function is crashing Chrome
But it didn't help.
Other threads mentioned that it's a bug in Webkit, but those were old threads and I couldn't find the bug report on Webkit's site.
The problem is that the header has a fixed width picture background and the navigation menu needs to stay within that width. I've since given up on HTML or CSS methods of accomplishing this. If you know of any, then please do share. So I've resorted to JavaScript (jQuery). And it works reasonably well, except in Chrome. The text actually increases in size for some odd reason.
Here's the simplified code in JSFiddle:
http://jsfiddle.net/alininja/j4jD9/12/
This gist of the code is this line:
$('body').css('font-size',(content_size-1)+'px');
For FireFox and Opera, the text size decreases to fit the header width, but not in Chrome.
If I run JSFiddle in Chrome everything works, but the funny behavior shows up on the actual website. This is happening on Chrome 17.0.963.56.
Thanks in advance!
If you want presentation consistency cross browser there is more involved than just setting font-size. You are assuming other font property defaults such as font-family are the same cross browser which they are not.
Use of a css reset will help
I have the following webpage:
A tall webpage with only a vertical scrollbar and no horizontal scrollbar. The document and window therefore have the same width.
When I ask IE8 for $(document).width(), it returns the viewport width including the vertical scrollbar. FF returns the right answer.
I cannot use $('body') for this, because it returns the same width as the window object (it is set to 100% somehow, so it doesn't work when the page gets smaller).
How can I make IE8 output the right value? Thanks in advance.
UPDATE
I actually did some more testing to my problem. and I found that when the horizontal scrollbar becomes visible as well (because of a smaller window), IE8 DOES get the right size. So this makes my problem even more complicated because I can't set an ugly if(IE8)-hack.
UPDATE2
The problem lies in my CSS and jQuery.
The actual case seems to be the problem:
My css says:
body
{
overflow-y:scroll;
}
IE8 doesn't count this as part of the body, but IE7 does. How to fix this? Call jQuery for a fix?
I put this problem to the jQuery crew: http://bugs.jquery.com/ticket/8048.
They don't think it's a bug. Their advice is to use $('body').width(). And this does indeed the job for me.
I still find it strange that the body in IE8 is adjusted to the scrollbar, but the $(document).width() stays the same. I used this jsFiddle for testing. It results in the same glitch, but jQuery thinks it's ok, because W3C doesn't say anything about it... Or something like that.
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.
Does $('#idOfLememt').outerHeight(); yield same result for all browsers? Any thing different for IE7?
Just go to http://api.jquery.com/outerHeight/ with the different browsers you want to test and see for yourself (on Mac OS X so can't check IE for you). It looks like the DOM in the demo has all possible styles that would affect this included.
Most of the time you can rely on jQuery to do it's thing and give you consistent results across browsers, that's one of it's main reasons for being after all.
Edit: Of course this won't be the case if the browser messes up with something else, for example if your container isn't fixed height and IE renders something inside your container with a different height for whatever reason then the result would be different. You are however pretty much guaranteed to always get the same result as the amount of pixels used on screen.
Like SLaks said it should work fine.
There is one downfall you might run into though if you aren't explicitly setting margins and padding in your CSS. outerHeight() will include padding and border always and if includeMargin is true than it will also include margins. With some padding/margin discrepancies across browsers... ahem... IE... you may get different calculations unless you've explicitly set the border, padding and margin on the element in question.
It should work fine. (Unless you have other layout issues)