Fixed
FS#1667 scrollbar flickers in IE8
CSS, XHTML, JS, Browsers
-
2009-04-08 coreyh9
A flicker happens in the scrollbar of the edit textarea whenever a key was pressed in IE8. This results in displaying the text where the cursor is not located if the text is longer than the text area, thus the user has to scroll back down to where the cursor is to type. However, when the user starts to type the same thing happens (bringing the screen back up from the bottom where the cursor is. When compatibility mode or adding a meta tag is used, the problem doesn't occur. *Important thing is this happens when the text is long (scrolling is required) in the textarea. -
2009-04-08 ach
More info on the mentioned meta tag: http://acidmartin.wordpress.com/2009/03/21/using-the-ie8-x-ua-compatibility-meta-tag/ -
2009-04-08 ChrisS
E.g. try this page http://www.dokuwiki.org/devel:parser, edit the page, scroll down halfway and start typing. -
2009-04-08 coreyh9
Chris,
Is the wiki with the Meta Tag fix or other fix? -
2009-04-08 ach
As far as I can tell, there are two erroneous behaviours involved:
1. If a textarea has its width defined with a percentage value (here: "width: 100%;"), the focus will always be at the bottom of the textarea. Ie. the line where the cursor is will jump to the bottom, but *stays* there. So, there's only one jump involved, which is strange, but okay. (This is definitely a bug in IE8 and not in DokuWiki.)
2. The locktimer.refresh() in lib/scripts/edit.js causes the jumping around, but only combined with the percent width. When the percent width is removed, everything works fine. And if the locktimer.refresh() is removed, everything works fine as well. -
2009-04-08 ach
Attached reduced test case for IE8 bug. -
2009-04-08 ChrisS
If its the combination of locktimer.refresh() with a percentage width, a fix which replaces the width:100% with an actual pixel value - calculated to be the same as width:100% may solve the problem. -
2009-04-09 ach
Replacing something like "width: 100%" with a JS calculating it, causes me a headache. ;-)
For the moment (unless we find another solution) I would rather go with the X-UA-Compatible meta tag.
I have to correct myself: The problem is not caused by the locktimer.refresh() but by the onkeyup event that calls it.
Good news: Using onkeydown or onkeypress instead fixes the jumping around. Shall we go with onkeypress instead? (Should not affect anything, should it?) -
2009-04-10 ach
I just sent a patch that gets rid of the wild jumping around that makes it difficult to edit the text at all.
That part where the cursor is, will still jump to the bottom of the visible part of the textarea.
As this behaviour does not really disturb the editing much, I will close this bug report now.
If you like to get rid of that behaviour as well, just delete the width for textarea.edit in design.css (for the default template). -
2009-04-10 ach
fixed in devel, see comment for further information -
2010-03-02 casper
Workarround without changing files: I found out, that if you disable line break in the editor, the problem went away (for me). - Related tasks:
