Script Error When Editing a Content Editor Web Part (CEWP) in IE8

0 minute read

I’m not a big fan of clunky workarounds, but they do have their place in the world.

This one occurred with a SharePoint 2007 site and IE8. Now I know that by default, this should work fine, but I’m not the first person to run across this issue.

It may happen that if you are running IE8, add a Content Editor Web Part (CEWP) to a page, open the Tool Pane and click on the Rich Text Editor button to edit it, you’ll get a script error. The error will look something like this:

Message: Invalid argument.
Line: 5739
Char: 2
Code: 0
URI: http://[YourWebApplication]/_layouts/1033/HtmlEditor.js

The workaround is to go into Compatibility View. Once the page refreshes in that view, things will function as expected. I don’t know why, and it doesn’t fix the problem, but you can get your work done.  It’ll satisfy my user until we upgrade to SharePoint 2010.



  1. Hey Mark,
    Did this happen with hidden CEWP hosting Java code?

    I got one for you. I’m using InfoPath 2010 in a doc library. Using IE8, pages load in the middle, rather than the top. This is not observed in FF 3.6 so it’s browser-related. I found an instance of this in IP2007 via Google. The fix was to place a 1 px X 1 px (set all the colors to none) button as close to the page as possible. (colors off is key, otherwise you see this weird grey-bracketed thing in its place). worked like a charm. I’m interested to see if there are any other ways to solve this issue?

    • Deb:

      No Java, but, yes, JavaScript. I decided not to even try to figure out the root cause since we’re basically throwing away a lot of what’s there in our upgrade to SP2010. We have a workaround, so we’re good for now.

      I have no idea about the InfoPath thing. It sounds like it is something which might be caused by whatever custom branding you have in place. I always warn people about using these little band aid things they find out on the Web because 1) you’re probably not addressing the root cause, and 2) you may well break something else. It’s always better to get at the specific issue in your environment, IMHO, and fix that.



Have a thought or opinion?