Probably related:

When opening a page on the English wikipedia with Internet Explorer, an error message appears and the page has to be re-opened. When making changes and visualising them, the changes are lost, so that I had to make the changes again and to save them without visualising them.

More:

When I look at the error info collected by MS, it says this is error code 0xc000005.
 Pressing "refresh" on this page helpfully caused it to crash [yet again] and generated the following Microsoft goobledigook:
 The instruction at 0x3fa07b98 referenced memory at “0x00000008”. The memory could not be “read”.

It's actually quite clear: it's trying to dereference a null pointer.

More:

I'm getting this on IE 8 with XP whether I run in compatibility mode or not. I use the Monobook skin. 95% of the time when I hit refresh on my Watchlist IE loses the tab and then recovers it. I don't get the error when navigating to (or refreshing) other pages, and I don't get it the first time I open my browser and navigate to watchlist

Cannot reproduce on Win 7 x64 Ultimate with IE 8.0.7601.17514 on x86 or x64 editions

Not saying it's in any way related, but the symptoms sound strikingly similar to a problem a relative was having with Hotmail crashing Internet Explorer on Windows XP; the solution was to uninstall Silverlight - see e.g. http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_programs/hotmail-crashes-when-try-to-send-or-reply-to-email/76fa89ef-41a4-4951-9edd-c821b13c4038 and http://answers.microsoft.com/en-us/ie/forum/ie8-windows_7/hotmail-silverlight-crash-issue/96ac7941-034c-e011-8dfc-68b599b31bf5 (other search results suggest Flash or Shockwave can sometimes cause this as well).

chrisd857 wrote:

Per MarkAHershberger's request, here are more details of the problems.

Several times, when I go to a Wikipedia page, IE gives me this error:

X We were unable to return you to wikipedia.org.

Internet Explorer has stopped trying to restore this website. It appears that the website continues to have a problem.
What you can do: 
  Go to your home page 
  Try to return to wikipedia.org 
  More information

It has so far been solved by clicking on the "Try to return to wikipedia.org" link. But that doesn't stop its recurrence.

The second problem is that while viewing Wikipedia, usually when I click a link to see another Wikipedia page, two tabs (which don't seem to necessarily be Wikipedia pages) will suddenly refresh. The two tabs sometimes include the tab I'm in, sometimes not.

njackson1 wrote:

When going into Wikipedia via search engine, Experience IE 8 forced close with windows XP also windows vista. If opening Wikipedia in a new tab or window- no issues encountered.

The exact err seen in comment 2 shows up here:

http://ryreitsma.blogspot.com/2011/09/internet-explorer-8-crashes-with-jquery.html

http://stackoverflow.com/questions/7192637/ie8-crashing-on-reload-only-when-site-on-localhost-only-when-javascript-is-enabl

Seems to indicate that upgrading to jQuery 1.6.3 works around the crashing bug; looks like we have 1.6.2. (1.6.4 is current release.)

These are problems of M$ not of MW, sorry. The browser should never be "crashable" by a website. But you can even use a relative simple RegExp to make IE crashing. Did you try to disable JavaScript after logging in?

It appears that this is the bug:

http://bugs.jquery.com/ticket/9823

You can prove this by setting your skin to Classic (or any other skin that doesn't use a background image) and observing that it no longer crashes when you go to a WP page from an outside site.

Use http://commons.wikimedia.org/wiki/User:Magog_the_Ogre/cleanup.js and you secureley get a crash with IE! Hehe! (No, I don't have this script enabled because it's evil...)

I think the jQuery selectors which work with regexps maybe causes this behavior.

neilk wrote:

I upgraded jquery to 1.6.4 on trunk. Please test this in every way you can.

neilk wrote:

FYI, there is some change to submit button handlers that occurred here, which we know already affects Upload Wizard. Be sure to check that in any app that uses jquery and submit buttons.

The jQuery fix is deployed to http://test.wikipedia.org. The way to test this is to search for "site:test.wikipedia.org" on Google or Bing (or probably other places), and then visit one of the URLs.

More importantly, though, please test all Javascript-y stuff (read, everything) on http://test.wikipedia.org . As of this writing, there will be a pretty serious known issue with UploadWizard (which Neil is close to a fix on), but everything else *should* still work.

(In reply to comment #15)

The jQuery fix is deployed to http://test.wikipedia.org.

You mean you deployed a full jQuery update there? Since the fix is *one line* (see https://github.com/jquery/jquery/commit/5c4a9cc001fcd803efa65ff95571c72cbdafbe69/ ) why don't we just patch it in and upgrade jQuery in trunk but not in 1.18wmf1?

(In reply to comment #16)

(In reply to comment #15)

The jQuery fix is deployed to http://test.wikipedia.org.

You mean you deployed a full jQuery update there? Since the fix is *one line*
(see
https://github.com/jquery/jquery/commit/5c4a9cc001fcd803efa65ff95571c72cbdafbe69/
) why don't we just patch it in and upgrade jQuery in trunk but not in
1.18wmf1?

Well, there's actually an XSS vulnerability in jQuery as well. I don't know how big that one is yet.

Regardless, ship is leaving the dock on this one. I think at this point we're better off biting the bullet.

Fixed with jquery 1.6.4 update, r99231.

tagging bugs for Marcus to look at