Internet Explorer’s weird vertical scrolling bug with insertBefore

07 Oct

I ran across a strange bug in Internet Explorer yesterday. It was very frustrating and took me quite a while to figure out, so I thought it might be a good idea to blog about it seeing how Google turned up no results that were of any help at all. This bug appears to only affect Internet Explorer 7 and only in Standards Mode, but is present right the way through to IE 9 if you’re using compatibility view.

I was writing a console application (more on that another day) which would take input, execute it and display the result directly above the input element, pushing it downwards. A fairly straightforward task, using element.insertBefore(), or so I thought. The containing element was a fixed height and width, after so many entries the vertical scrollbar should appear and the script should automatically scroll the area to the bottom. This is where the bug lies. In the following example, highlight the line of text with the grey background and press return repeatedly until the scrollbar appears:

[iframe 100% 220px]

If you’re viewing this page in any current browser, you can see it works fine. However, if you view the page in Internet Explorer 7 (or just view the fiddle in IE 7 compatibility view), you’ll notice that when the scrollbar appears its height sticks at a particular size and doesn’t change, no matter how many times you press return. When you scroll this “stuck” scrollbar to the bottom it shrinks, but not immediately. You have to keep scrolling until you get all the way to the bottom for the scrollbar to be the correct size. Alas, this doesn’t fix the problem, the next input will reset the scrollbar back to its stuck height.

I tried numerous ways of working around this problem – I tried using the proprietary element.insertAdjacentElement() method, I tried checking (and even setting!) the element.scrollHeight property through script and it stayed the same after each input. Finally, I found a semi-solution. Instead of inserting the result before the input element, I appended it and then used element.swapNode() to change places. Unfortunately, this presented a new problem – the input element loses focus. It’s not difficult to refocus the element, but I decided to investigate further and discover the cause of the bug. I tried to reproduce it at and I couldn’t, so I copied all my code across and made sure the bug was present. Then I whittled away at parts of the code, chopping bits out until I was finally left with the skeleton above. At this point, I just started chopping bits out of the container’s style, which looks like this:

.ContentPage { 
    border:1px solid black;

I noticed at this point that that the width style was redundant so I removed it. Surprise, it worked! No more scrollbar bug. So, if you ever run into this issue whilst testing Internet Explorer 7 then check to see if the element has the width style set unnecessarily. If you really need it to be there, then your only option may be the element.swapNode() and refocus method.

Update - it seems removing the width style caused another problem in the form of one of Internet Explorer’s “disappearing content” bugs. When I adjusted the height of the <textarea> element, the container element disappeared until I toggled another style that affected its layout. I eventually went with applying the left and right styles to solve both problems.


Tags: , , , , ,

Leave a Reply


  1. links for 2010-11-04 « sonofbluerobot

    November 5th, 2010 at 12:32 am

    [...] Internet Explorer’s weird vertical scrolling bug with insertBefore « What the Head Said (tags: ie7 iebug) [...]