I'm getting different values for offsetwidth for the same element in Firefox and Chrome, which makes the element display incorrectly. Please suggest some solution so as to have consistency.
I'm having a similar issue when I load content via AJAX with Firefox 12.
Both Chrome and IE9+ report the offsetWidth correctly after the the ready state is complete, but Firefox hasn't seem to have calculated it yet.
If you check a bit later (even delaying a half second sometimes), Firefox has the right width.
I suspect someone tried to make Firefox faster by firing the ready signal before they should be.
The original poster didn't give a lot of details, but I suspect this might be the problem.
Edit: P.S. The only way I've found to get this to work correctly is to delay and keep checking back until it has the right value.
I had problem with offsetHeight, I replaced it to scrollHeight and it works for me.
Related
This really has me scratching my head.
The OPTION text is cleared using this code in a Snippet:
document.querySelector('option').textContent = '';
<select>
<option>Ipso</option>
</select>
It also works in a CodePen, plus it works on my website.
However, in JSFiddle it fails – but only in Chrome.
If I set textContent to anything prior to clearing it, it then works.
This issue doesn't seem to occur with any other type of element.
If I use innerText or innerHTML instead of textContent, I get the same behavior – but again, only in Chrome. jQuery's text() method also gives the same behavior.
Is this a Chrome bug or a JSFiddle bug?
I don't know the reason for the bug, but try setting the load type (click the cog in the top right corner of the JavaScript frame) and select no wrap - in <body>.
It works on the Chrome browser on my phone (whilst your fiddle didn't), and could possibly explain what's gone wrong.
Given a complex JS application produced by GWT I need to use the complete browser area WITHOUT let scrollbar compare but not disabling them because there's a couple of exception to the rule, i need then to calculate the client area and since the tool selected it would be better directly in GWT but as it is supported also pure JS solution are acceptable.
as usual all browsers (chrome, safari, ff) except IE11 works fine with a standard solution of
rootPanel.setPixelSize(Window.getClientWidth()-1, Window.getClientHeight()-1);
but when it's used in IE11 on a screen 1440x900
the value of getClientHeight is 1440x845 (seems ok) but after rendering using this space scrollbars compare wasting space, exactly 10pixels..
rootPanel.setPixelSize(Window.getClientWidth()-1, Window.getClientHeight()-10);
seems to solve..where are gone this 10 pixel comparing the result with other browsers?
I think contents are not relevant since the size is set on body and first div
<html>
<head>...
<body style="width:1439;height:xxx;">
<iframe out of visibility (position absolute and visible false
<table style="width:1439;height;xxx">
and so on
Any guess where 10pixel can be lost?
Edit: I was forgetting an important detail: all happens when browser is maximised, if the browser is n't all seems working as expected!!!
Edit: looks like something close if not the same of
$(window).height() issues in IE and FF
change just the origin of my JS code that comes from GWT but at the last stage should be the same, but still not solution
Solved: when maximized the actual size is available late...the resize must take the size in a deferred moment, the module load usually implemented in GWT isn't the right time for this browser in the specific state..
I'm using jqRangeSlider in creating multiple instances on my website.
For some reason, and only on Chrome - it takes a lot of time to render the sliders (about 1.5-2 seconds each X 9). The sliders also move very slowly (again, only chrome).
FF and IE are working perfectly.
I tried removing other JS files, but for no avail. I'm not even sure how to debug such a problem.
Would really appreciate any idea.
OK, I've found the bug.
The issue originated, oddly enough, from a direction:rtl css property on the body element :\
Now works, as usual, faster than FF and IE.
Hope this will help someone.
A recent update by Google for their Chrome browser (31.0.1650.57 m) has caused an issue with jQuery's buttonset() where buttons are now showing vertically rather than horizontally as they should.
I found a work-around which is to set the 'display' css attribute to 'inline-block' after the initial buttonset() call. Attempts to set this attribute prior to this call are ignored (though they worked fine for prior versions of Chrome and work well in FireFox).
My question is whether others have experienced this and if so, can they shed light on why this is happening and whether there is a better way of addressing this than with my work-around?
http://jsfiddle.net/4t6j5/2/ (this seems to be working normally)
http://www.periferi.nu/#filter=.utstallningar (this does not)
Se the jsFiddle where I have tried to reproduce the error using the parts that are erroneous.
So the problem is that in IE8 and down the read more element starts jumping a whole lot instead of simply sliding in from below when the mouse is over the image. Works perfect in most modern browsers but in IE8 and down it starts jumping (especially when hovering the p elements, for some reason).
It appears that when the code from that part is isolated it works.
Why does it behave differently in IE? Any help is appreciated!
Ok after endless hours I have captured the bug in my css file. Strange case but thanks WTK for the direction. Turns out:
html {overflow-y:scroll;}
Was the main problem for some for me unknown reason.
If someone sits on further information as of why this happens in IE please share.
http://jsfiddle.net/4t6j5/3/ (Bug hunting fiddle)