In a desktop system, yes - in a very limited embedded system, that's pretty tough.

One issue is that in the case of images in browsers, it's very hard to tell until it's too late.  You can't trust the "width" and "height" parameters in the "img" tag, assuming they're even there, and the file size is no indicator as well.  You have to start decoding the actual image file after you've downloaded it to figure out how much memory it's going to take - but you may not have survived the download.

In an embedded system, what typically happens when the memory gets low is that an "out of memory" daemon, called an "OOM killer", kicks in and starts killing processes until enough memory comes free. Unfortunately, OOM killers are hard to control.  In our case, for the browser to work, the two largest processes, the Flash Player and the browser, both have to survive the massacre.

If the browser is killed, the system will typically recover - however, if the Flash Player gets killed, then things go sideways.

There are other processes, which if chosen by the OOM killer, will cause the system to hang.

It's a tough problem, not one easy to solve.  When the devices were originally specified, we did not intend to put full browsers on them, however, we thought we try to make *something* available, even if not perfect.