You really want to post a link that locks up people's browsers? I can think of a dozen ways to do this, but why would I inconvenience people just to show off a trivial self-evident fact?
And "crash" is an exaggeration. The browser is prevented from functioning until it figures out that its processing power is being absorbed in something pointless, for example by badly written JavaScript:
function loop_forever() {
while(true) {
}
}
A modern browser assigns a thread to each process and monitors each thread, so it can act to stop unresponsive threads. That's what happens in this case. It's not a "crash", unless bringing a car to a safe stop at a red light counts as a crash.
> A modern browser assigns a thread to each process and monitors each thread
That would be ideal, yes. Firefox still doesn't work this way, I think? Chrome (or rather: SRWare Iron in my case) does, though: this link, which I obviously had to click (I make no excuse :P) did crash the tab I opened it in, but it had zero influence on the rest of the tabs, or the interface in general.
So on that basis, Firefox isn't a "modern browser". :)
Any JavaScript that hogs the thread it's running in will cause this kind of problem. If the thread happens to be the same one the browser is running under, then "crash" is a fair description.
Well, it certainly crashes on all my Windows flavors (XP, 7, 8x64). Firefox isn't exactly the poster child for stability, can't tell whether it ever was...
Any browser that can be locked up by a bit of JavaScript that hogs the thread really needs to have NoScript enabled. The reason is there are too many easy ways to write a processor hog, either intentionally --
function hog_processor() {
while(true) {
}
}
-- or unintentionally, by not knowing something about programming:
function beginner_error_run_forever() {
for(var x = 0;x != 10;x += .1) {
// code here
}
}
You're right, but Today's World really relies on JavaScript and browsers development could, well, weigh it a bit more. Fighting on speed records might look good on browser's CV but for me personally doesn't matter zit - I'd take a stabler Firefox over a speedier one any second (I say this after 2 crashes today, on 2 different machines).
After freezing for a few seconds it really crashed my Firefox, showing the crash reporting UI and everything. In chrome, the tab crashes too, but not the whole browser.
For those interested, the responsible code is located here:
dontclick://fiddle.jshell.net/n3Wa3/show/light/
And here is the code:
<script>
function Hackology()
{
var buffer = '\x42';
for (i =0;i<666;i++)
{
buffer+=buffer+'\x42';
document.write('<html><marquee><h1>'+buffer+buffer);
}
}
</script>
its clearly mentioned that it will lock up your browser. If you had tabs open I am sorry for that but you would have given the title of this post some thought :)
the while(1); thing could be explained easily, but the code for this one (written below) is not simply an endless loop
> ... the code for this one (written below) is not simply an endless loop
You may find this enlightening: Not only do nontrivial programs sometimes have unevaluated ways that will prevent their termination, but it's been proven that there cannot be a deterministic way to prove that a program will or will not terminate.
The Turing halting problem (will a given program terminate), and Godel's Incompleteness Theorems (nontrivial axiomatic systems can make true statements that cannot be proven), are connected -- each implies the other. And both have been shown to be more than educated guesses about reality.
But any bit of trivial JavaScript code can crash a certain class of browser (the class without independent threads) -- it doesn't require even a small bit of cleverness.
It's just not newsworthy, and it's a public nuisance to post such examples -- I mean a working example, as opposed to an inert code listing.
I am sorry, but I found the code behind it interesting so posted it.
I put it on jsfiddle! If you were smart enough, you could have accessed the html behind the page easily.
My point being, browsers should be able to recover from such code. What if some site's ad code has this in it. It shouldn't be able to crash my entire browser.
>> it's a public nuisance to post such examples -- I mean a working example, as opposed to an inert code listing.
> I am sorry, but I found the code behind it interesting so posted it.
You should have posted a listing, not a working copy. That would have been the civilized, non-destructive thing to do.
> If you were smart enough, you could have accessed the html behind the page easily.
I did. But if you were smart enough, you would have done that and avoided performing an unscheduled test of the less technically skilled visitors' browsers ability to handle broken code.
> My point being, browsers should be able to recover from such code.
Why not set your car on fire? A modern car should be able to tolerate the flames, right? Where's your sense of adventure?
You just aren't thinking. This is a public forum visited by people representing all levels of skill.
Yep. Back in 2008 or thereabouts, I threw together http://crashmybrowser.com/ (note that this page will not immediately crash your browser, it's very polite about asking first). I only spent a short amount of time on it and haven't touched it since, but at a quick check, it looks like at least a couple of the tests are still effective.
The site has a note, under "why", along the lines of resource limitations and process separation for tabs being a good idea. 5 years later, it still is.
On the plus side, all of the browsers have changed their UI a lot during those 5 years.
edit: looks like Chrome (or Chromium) has aged more gracefully than Firefox. It handles everything on the page with a minimum amount of fuss. Good. :-)
26 comments
[ 5.1 ms ] story [ 63.1 ms ] threadAnd "crash" is an exaggeration. The browser is prevented from functioning until it figures out that its processing power is being absorbed in something pointless, for example by badly written JavaScript:
A modern browser assigns a thread to each process and monitors each thread, so it can act to stop unresponsive threads. That's what happens in this case. It's not a "crash", unless bringing a car to a safe stop at a red light counts as a crash.That would be ideal, yes. Firefox still doesn't work this way, I think? Chrome (or rather: SRWare Iron in my case) does, though: this link, which I obviously had to click (I make no excuse :P) did crash the tab I opened it in, but it had zero influence on the rest of the tabs, or the interface in general.
True. The current Firefox locks up, then announces a crash:
http://i.imgur.com/vgd8PLV.png
So on that basis, Firefox isn't a "modern browser". :)
Any JavaScript that hogs the thread it's running in will cause this kind of problem. If the thread happens to be the same one the browser is running under, then "crash" is a fair description.
For those interested, the responsible code is located here:
dontclick://fiddle.jshell.net/n3Wa3/show/light/
And here is the code:
the while(1); thing could be explained easily, but the code for this one (written below) is not simply an endless loop
You may find this enlightening: Not only do nontrivial programs sometimes have unevaluated ways that will prevent their termination, but it's been proven that there cannot be a deterministic way to prove that a program will or will not terminate.
The Turing halting problem (will a given program terminate), and Godel's Incompleteness Theorems (nontrivial axiomatic systems can make true statements that cannot be proven), are connected -- each implies the other. And both have been shown to be more than educated guesses about reality.
No. Waited about five minutes. No crash.
Opera did crash though.
Chrome for Win32 here.
It's just not newsworthy, and it's a public nuisance to post such examples -- I mean a working example, as opposed to an inert code listing.
like this: view-source:http://fiddle.jshell.net/n3Wa3/show/light/
OR
http://jsfiddle.net/zalun/n3Wa3/embedded/html/
My point being, browsers should be able to recover from such code. What if some site's ad code has this in it. It shouldn't be able to crash my entire browser.
> I am sorry, but I found the code behind it interesting so posted it.
You should have posted a listing, not a working copy. That would have been the civilized, non-destructive thing to do.
> If you were smart enough, you could have accessed the html behind the page easily.
I did. But if you were smart enough, you would have done that and avoided performing an unscheduled test of the less technically skilled visitors' browsers ability to handle broken code.
> My point being, browsers should be able to recover from such code.
Why not set your car on fire? A modern car should be able to tolerate the flames, right? Where's your sense of adventure?
You just aren't thinking. This is a public forum visited by people representing all levels of skill.
The site has a note, under "why", along the lines of resource limitations and process separation for tabs being a good idea. 5 years later, it still is.
On the plus side, all of the browsers have changed their UI a lot during those 5 years.
edit: looks like Chrome (or Chromium) has aged more gracefully than Firefox. It handles everything on the page with a minimum amount of fuss. Good. :-)