We have recently started using WMD editor and found that in IE 8, it just goes on increasing the scroll size of the page by simply increasing the size of the textarea endlessly. The only option left is to close the browser after that causing lot of frustration. you can check wmd-editor demo here. does anybody know of any solution to this issue ?
after a lot of trial & error, we finally found the issue and fixed it ourselves. None of the parent container of the div in which the wmd editor is placed into should have the css property position defined. else, it will break the editor in IE8.
Related
Just using 'mix-blend-mode:overlay' on a text element and it causes my browser to scroll really slow while the text is in the screen view. As soon as you scroll past the text item, the scroll goes back to butter smooth.
The lag effect, which affects both chrome and firefox is solved if I remove the mix-blend-mode.
Has anyone else had a similar problem with mix-blend-mode?
Not sure if this will help you in your case, but I had a 'transform: scale(-1);' set on element that had 'mix-blend-mode' enabled. When I removed the transform the performance was silky smooth! So, if you're using any sort of 'transform' I'd remove it and look for an alternative solution if possible.
It may also help if you set 'isolation' property to the layer beneath, as per example here: https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode#HTML_example
My jScrollPane (division) works well in IE and Chrome. It may be of some significance that I am also running JQuery MouseScroll and hoverintent. Again, these functions work fine in IE and Chrome.
The division is displayed properly in Firefox, as is the vertical scrollbar. There's about 50 lines to scroll down through.
In Firefox, the dragger fills the entire length of the vertical bar and doesn't move. The dragger and the arrows do respond to mouseover, but the functions don't work.
Perhaps the scrolling action is functional, just that there is no space to scroll, because the dragger fills the entire region. I am unsure whether my jScrollPane works or doesn't in Opera or Safari.
I checked Google and found little directly associated advice, just to:
"Ensure that the division has a height specified (it does) and to try refreshing (no luck) in case the content (only text) needs to pre-load."
I wonder whether anyone can suggest any checks for me to make from their previous experience before I post any code to wade through.
This is only the second question tagged with jScrollPane & Firefox, so perhaps no-one will be familiar with this 'bug'. In which case I will create and post some reduced code which generates this bug in Firefox but not IE or Chrome.
Update: I created a 'test' scrollbar webpage to see if the bug would be replicated, and that works fine - so no need to post that for error-checking.
The problem must lie somewhere within my code on the site I'm working on.
So far I have identified that all the JavaScripts work and my custom jScrollPane CSS is fine. So it's just a process of elimination through each of the stylesheets now. I have a feeling the source of the bug may be in my custom reset CSS.
I'm confident I'll fix the bug, and will let you folks know either way.
The bug was in the CSS reset as suspected. Specifically, with the rule for column-count.
I had defined them (moz-/wekbit-/column-count) as '1' instead of the defining as 'auto' / not defining it at all.
This was from when I was experimenting with (CSS3) multi-column text. Presumably jScrollPane requires multiple columns. Not enough support yet for multi-column text to be worth implementing yet IMO.
I'm using Ajax TabContainer with a number of tabs,and IE as browser.
On one of the tabs, which is created and added dinamically, I'm showing a number of charts.
Sometimes some of the charts are missing, and after changing tab or selecting the area by mouse, the chart apears.
This problem exists only in production environment, in other words, in development environment there is no problem.
Thanks very much in advance for any help.
I could fix the issue, even though in a tricky way.
I forced the tabContainer to redraw after the page is loaded:
setTimeout(function() {
var tabIndex = $find("<%=TabContainer1.ClientID%>").get_activeTabIndex() ;
$find("<%=TabContainer1.ClientID%>").set_activeTabIndex(tabIndex);}
, 4000)
It does nothing but activating the tab which is already active.
However, I'm wondering if there is any better resolution.
to perfectly describe the problem look at (in firefox, my version=3.0.10!!):
http://musca-design.de/portfolio.php
when you click through the portfolio, apparently the scrollbar jumps to the bottom?
In Safari, Opera it wont, it stays at the top, which is what I want.
Is there a workaround or how can a tackle the problem?
The scrollbar (the page actually) jumps, because Firefox jumps to an anchor.Your links in your <li>-list e.g. point to URL#p05 - is there a reason for using those anchors?
There's no real way to prevent this but a solution has been posted here
Prevent default hash behavior on page load
Is there a 'valid' solution for the dialog to scroll with the scrollbar instead of still being fixed from the center of the inner window bound ?
There is some situation where the user may have a too small resolution to contain the dialog, and in that case part of the dialog maybe hidden.
You may have a Ok or confirm button in the hidden part, and then the popup may not be closed, nor validated ! Blocking situation.
I tried to change a css into the code from fixed to absolute, and then the dialog scroll with the page: great! But... Meanwhile doing this, opening another popup, do not position it again centered into the layout. Maybe a solution is to recenter the dialog on each onOpen event.
Any help welcome.
The dialog was written to be fixed and as such is not easily changeable.
You could change the position to absolute, but all of the IE hacks will force it to behave as fixed.
In SimpleModal 1.4.2 you can simply set fixed to false:
$('#myModal').modal({ fixed: false });
This worked for us on Chrome and IE all the way back to IE8. (We don't support IE7.)