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.
Related
I have a web page with some elements and Ant.design slider present too. Slider values is controlled by React state. When slider tooltip is turn on, slider is very slow down and in console I see a message [Violation] Forced reflow while executing Javascript took ....
When slider tooltip is turn off, slider speed becomes normal. Message is appear in console also if I'am only point a mouse on slider handle (without moving handle).
How can I fix bad behaviour with tooltip?
Thank's in advance!
Slider with tooltip is a standard feature that normally works well, so chances are you have some performance issue in your code.
See the accepted answer to Violation Long running JavaScript task took xx ms for some useful tips on how to locate problems.
For more detailed help you need to post your code, preferably as an executable example.
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.
When the browser is IE9 and it has a horizontal scrollbar, sometimes icons go missing from my CKEditor. This happens especially during Undo and when switching between source mode and back. The horrible part is that I can't replicate it outside my site (sorry no linking), but I can replicate it easily within it by simply adding a table and then pressing undo. The icons come back when I move my mouse over them (Maby I should do a video to demonstrate?).
I have no idea what is causing this so any suggestions are welcome. I don't touch the icons in my custom code at all. Have you seen a similar issue to this? What could be causing it? Is there anything I can try?
Added: YouTube demonstration of the issue happening
Missing icons:
Very weird. Seems that disabled buttons lose their icons. I see that you modified CSS a little bit - haven't you overwritten path to icons strip for disabled buttons as well? Or have you updated CKEditor installation recently, but without stylesheet you modified earlier? Maybe this is a cache issue - path is the same, but IE9 remembers old file where those icons were in different positions.
Turns out that it indeed was some insanity inducing IE9 rendering bug with CSS opacity.
For others experiencing this bug: I fixed it by manually editing the CKEditor editor_ie.css. There is a part like this: .cke_button_disabled .cke_button_icon{opacity:.3}. All I did was comment out the opacity, leaving .cke_button_icon{/* opacity:.3 Removed By Nenotlep */}.
Note that a "fix" like this is a Bad Idea, you have to remember to manually maintain the change in your code repository.
I've got many divs on the page (close to 20) which are both jQuery-UI resizable and draggable. There are also some css-based changes that are triggered on mouseover and mouseout for each div. In the middle of playing around with these divs, sometimes, one of them just "gets stuck", i.e. just can't be dragged around any more. Using the Firebug and the console, I've seen that it does have both classes: ui-draggable and ui-resizable but it's still just "stuck". Is this something that normally happens with too many divs on the page? Just jQuery-UI get stuck like this? Most of the time everything works as expected, sometimes any of the divs suddenly can't be moved.
My code to make things draggable was simple. For each div, I had a plugin that worked on itself, and part of its code was :
$this.draggable({
cursor: 'move'
});
I have recently encountered this problem and... I have no idea what the cause is. As far as I can tell it was probably caused by something happening around mouse handlers- possibly accidentally rebinding something that draggable was using, but I couldn't see any sign of it. Either way, draggable was failing silently and reverting the changes I was working on when it occurred did not help - the code which had worked at the start of the day was now also failing.
That is an indicator to me that something was weird with the way my browser and development server were interacting because that code worked earlier and now it had stopped. My solution was to stop the server, close the browser, run a git clean -fdx - careful with that one, other source control systems exist - on my project and then restart the server and client. Hey presto my old stuff worked - and the new code did too, once I popped it out of my git stash.
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".