This page crashes Internet Explorer, even version 9 and 10.
crashie8.com
crashie8.com
The most amazing part of this exercise has been analyzing the traffic trends. This page gets a crazy amount of traffic in Japan and China - I still can't figure out why.
It has also been a remarkable insight into the dysfunction that is Microsoft; I'll hear from some random Microsoft employee twice a year who became aware of the site and wants to fix it, after pointing to the closed "not a bug" thread on MSDN they all vanish (apparently keenly aware of how atrocious the IE team reacts to external interest/support.)
(The link on the page is just to a Google Group discussion, which doesn't appear to have participation from Microsoft.)
> Page Not Found
> The content that you requested cannot be found or you do not have permission to view it.
Did they remove the item?
Yesterday I ran into errors "String is undefined" when trying to augment String.prototype. Testing for undefined got me "undefined is undefined". Turns out it was a variation of a known issue they deem so unlikely that they won't even bother to fix it. (The issue is this one: http://msdn.microsoft.com/en-us/library/gg622929%28v=VS.85%2... ) If anyone wants to know the fix: you have to set the innerHTML of the parent element of the iframe to '' before detaching that element from the DOM. That actually stops code inside the iframe from running.
What I also love is the arrogance with which they suggest solutions, like on the page I linked: "If your application uses a programming pattern that is affected by this issue, you may wish to consider not removing the iFrames from the page."
Apparently IE doesn’t need to follow the robustness principle. http://en.wikipedia.org/wiki/Robustness_principle
If your TV crashed would you blame the TV program you were watching at the time?
People know the difference between software and content. Content should never be able to crash software.
I disagree with you TV example, however. If the same TV show repeatedly crashed one of the most popular TV models, consumers would blame the show.
Two characters are in a race: one to build an impervious record player, the other to design a record that - when played - sets up feedback in the record player sufficient to destroy it.
It's a stunningly simple intro to a fairly deep topic: NP completeness, input validation, etc.
I'm 99% sure that it was something invalid in the closed captioning.
I'm not positive, but I believe that it's possible for TV shows to crash TVs, which is why there are standards in that specify what kind of content you are allowed to broadcast:
people should know the difference, but they don't.
Not that there's anything wrong with that, but I don't think Chrome would be anything near what it is today without all of the google.com referrals.
In fact, you can make quite a case that "robustness" as defined that way is responsible for the horrible mess that HTML and cross-browser compatibility is these days. For instance, if you improperly close tags, or overlap tags, IE (and others I assume) will dutifully go about trying to figure out what you meant: being very "robust" in their interpretation of input outside the spec.
By implementing behaviour outside the spec (being "robust"), you are implicitly extending the spec, and every other browser has to implement unspecified behaviour in the same way.
Fun times.
Everyone create a script on all your websites that randomly implements this bug on some but not all pages (definitely not landing & home pages) then watch as little by little millions of users think their IE is broken and messed up and start using other browsers. A few sites alone wouldn't make a difference but over the course of its life even websites with normal amounts of traffic build up 30,000 unique visitors after a few years. Combined that would do some damage to IE's stability. Yes it's evil because you're deliberately crashing innocent people's browsers but aren't they evil/foolish for deliberately using IE and making us work harder to support it?
Sometimes users have to learn things the hard way.
I write web-based software. Every day.
I have made every browser crash and become completely non-responsive, many times over. Chrome. Firefox. Opera. All of them.
Now, this is mostly through JavaScript, when I do something stupid by manipulating the DOM the wrong way or some other funny thing. I fix it and keep going. Because breaking the browser is bad.
Want to report it to the vendor? Great. Fine. Making a website dedicated to the crash? Waaaay too much time on your hands.
If you are crashing them as often as you claim, you should be filing security bug reports - every other browser team will respond quickly to non-Flash crashes.
We have a winner. Want browsers to play nice? Write good code.
Time to report bug to Microsoft: 30 minutes. Time to create website for bug: 4 minutes. #justsayin
Seems like we're just trying to pick on IE here.
(FYI here's some HTML/JS for the Firefox bug... Resizing the browser caused the issue to manifest in Win7 with FF 13.0.1:)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd>;
<html xmlns="http://www.w3.org/1999/xhtml>;
<head>
<title>Test</title>
<script type="text/javascript"> window.onresize = function () { alert("gg"); }; </script>
</head>
<body>
</body>
</html>
(edited to acknowledge that this is a JS bug). And for the downvotes, at least provide a reason and/or a discussion.
I accidentally discovered some very simple HTML that reliably crashes Outlook whenever you try to view or preview the message a while back. I reported it and I think they eventually fixed it.
> I reported it and I think they eventually fixed it.
If you follow through to the MSDN discussion, it is from 2009. So "eventually fixed it" could apply in this case, only because the timescale is unbounded, but waiting years for a fix seems unreasonable.Edit with more info: Looks like removing any of the markup prevents the crash. "Removing the CSS, the div, the table, etc all cause this code to not crash IE"
<style type="text/css">
#a { margin: 0 10px 10px; }
#b { width: 100%; }
</style>
<table>
<tr>
<td>
<div id="a">
<form id="b">
<input type="text" name="test"/>
</div>
</td>
<td width="1">
</td>
</tr>
</table>
Removing the second td is enough to make the html not crashing on IE 9. The "crash" manifests itself in some kind of an infinite loop (one thread jumps to 100% CPU and stays so). Then the "recovery" mechanisms kick in, reloading the page, blocking again... :) Can anybody reduce it even more?Closing it in any of the normal ways is failing, I had to do end task.
Successive attempts to load the page don't even need for me to click anything for it to crash hard.
No? Anyone? Guess I'm wearing a black hat today.
The corresponding analogy would be if the Crab's record player broke any time a particularly bad pop song came on. It could tell by looking at the song whether or not it would break, but the designers didn't bother to fix it because no one wants to listen to bad pop music anyway.
The analogy seems to fit there, enough to make me smile anyway :)
(using 9.0.8112.16421)
That headline sounds disingenuous and somewhat flamebaity given that 10 is still in development and the latest public version available on Windows 8 does not crash.