You asked why the browsers know to do this, and Steven's answer does explain technically why they know (because the appropriate option is turned on), but not why the functionality was added. I will attempt to cover the other part.
In the grand old days of the internet, there were two different types of names: domain names (which may include subdomains), and host names. Hosts which belonged to a domain would have names under that domain.
So, the mit.edu domain would have hosts like trillium, athena, and better-mousetrap within it. It may also have subdomains, like csail.mit.edu, which could have hosts like cgh and vision03 within it. It's also possible to have a host which has the same name as a subdomain, so you could have a host called csail in the mit.edu domain.
Hosts can be named almost arbitrarily. In large networks, the hosts might be named after the user who commonly uses it (e.g. cgh), the department it's doing work for (project Athena, Comp Sci & AI Lab), or the function it performs (computer vision); or it may be given an arbitrary name just to distinguish from other machines (e.g. trillium, better-mousetrap).
Now, to access one of these hosts if you're not part of their domain, you need to use their "Fully-Qualified Domain Name", or FQDN, which would be:
trillium.mit.edu.athena.mit.edu.better-mousetrap.mit.edu.cgh.csail.mit.edu.vision03.csail.mit.edu.csail.mit.edu
Any of these hosts may offer one or more services to the network - remote dektop, ssh, telnet, ftp, email, web, gopher, dns, network time, or anything else. On the other hand, any host may also offer no services, and simply act as a client.
Many services are discovered automatically, via dns, like dns itself, as well as email (smtp), and some things like VOIP. But many other services are accessed arbitrarily, by humans, and so humans need to know the name of the hosts which those services are on.
In order to make them easier to remember, a few well-known services, like ftp, eventually started to be used as host names for hosts which only (or primarily) provided that service. Later, when the World Wide Web became popular, www became the well-known hostname which identified the primary webserver in the domain. Other hosts might still offer web services, but commonly the www host name became instrinsically associated with websites.
(There is also the ability to create an alias hostname, so that a host which provides multiple services can be known by multiple names, to make each easier to remember, like having the host trillium be also known by the aliases www and ftp if it was the primary server for those services on the domain - but that doesn't change the core of the discussion.)
As the web became significantly more popular than most other online services, the www association became so much a part of the internet, to the point that for most websites, you could just assume it was there - if I told you to go to yahoo.com or mit.edu, you would probably assume that I meant www.yahoo.com or www.mit.edu. (From memory, historically the latter would have been a bad guess - I vaguely recall that MIT's primary web server used to be located at web.mit.edu, but eventually the www alias was added to assist those who guessed that.)
This is especially true for most websites, where the www host is the only directly-accessed host in the domain for most people.
So people started taking short-cuts, by just saying yahoo.com or mit.edu, because "everybody knew what you meant".
Eventually, we ran into the opposite situation. Now, because many people are used to saying yahoo.com when they meant www.yahoo.com, other people who aren't used to that started typing yahoo.com instead of www.yahoo.com.
Now, it used to be generally tricky to use a second-level domain as a host name. While there is nothing in the DNS rules which stops us from doing so, the difficulty is that the authoritative dns name server for a particular host is dns server for the domain that contains it. We can create a host csail.mit.edu, but it is part of the mit.edu domain, not the csail.mit.edu (sub-)domain, so it's host entry must be defined in mit.edu's name server. Meanwhile the host www.csail.mit.edu is part of the csail.mit.edu (sub-)domain, and is served by that domain's name server.
Now, this is not a big problem when both domains (mit.edu and csail.mit.edu, in this case) are controlled by the same, or cooperating, organisations - we can add the entries in both domains, or contact the owner of the parent domain and ask them to add in the relevant entry for us.
But if we want to put a host at mit.edu, then that host is part of the edu domain, and the appropriate dns name servers for that domain are not controlled by our organisation. So it's harder to get the host name created, and many domains did not do that (like businessbrief.xyz, which belongs in the xyz domain, whereas www.businessbrief.xyz belongs in the businessbrief.xyz domain).
So browser vendors assisted the unwitting users who might type in a bare domain name which did not have a host attached, by subsequently searching for a host called www within that domain.
Now, this may not be the right thing to do in all cases, which led to disagreement about whether to do it at all, which led to the configuration options that Steven posted about.
