

Broken Browsers Part One: The Back Button - blasdel
http://blog.dreamhost.com/2009/05/13/broken-browsers-part-one/

======
silentbicycle
A lot of problems are actually really simple if you "just" do caching
properly. But, you know what? In general, _caching is really hard to do
properly._ I think the problems with the back button stem from ambiguity in
what back actually means. Does it revert a form transaction? Does it restore
the cached value of the previous page? Does it go back to the previous URL,
updating the content? Since the web uses a stateless protocol, it's unclear to
what extent the cache is still valid.

(Also: Does anybody else find articles with large, semi-relevant images
between nearly every paragraph to be incredibly irritating?)

~~~
dejb
I think the description provided in the article is pretty unambiguous. Perhaps
other people might want different behaviours but what was described is the
article is exactly what I want.

I don't care if the cache is valid. I don't care if the webmaster thinks the
page needs to be updated every 10 seconds. All I want is the previous page
exactly as it was when I last viewed it. It's my browser and it should do what
I want. If the webmaster is relying on browser behaviour to ensure I don't
resubmit a form then frankly they are asking for trouble.

~~~
ggchappell
Agreed.

And I think his observation on back vs. browser tabs is very insightful. When
browsing links, as on HN, I always open a new link in a new tab. And I think
the reason is exactly what he says: I don't trust the back button to get me
back to the right place quickly. Killing a tab _does_ do that, and so I use
tabs.

------
wvenable
The web browser has very little to do with this problem; it is merely doing
what the website has told it to do (or not to do).

I run a small forum where clicking back and forth between forms without losing
what you've typed is a very important feature. It works _exactly_ the way this
author wants in _all_ browsers because the headers are set correctly.

Similarly, I also work on a big web application where clicking the back button
and getting stale information is bad. Again, the website sets the proper
headers and the information is refreshed (if appropriate) or left alone (if
appropriate).

This is not a browser issue. The differences are likely caused by how
different browsers implement (or don't implement) the standard.

~~~
ido
Exactly.

A lot of so called "browser problems" are actually website problems.

And who's the genius that decided accepting malformed html was a good idea? If
the first browsers gave an error (with line numbers and explanations) instead
of trying to render incorrect html people would just go back and fix it.

~~~
cousin_it
I've taught a lot of people the basics of HTML. Always started the same: open
a text file, type in "Hello World", save as .html, open in browser, see Hello
World. Woohoo, instant rush, this stuff isn't so complex after all. Don't want
to see this:

    
    
        Error at line 1, DOCTYPE expected

~~~
ihumanable
Your argument is that you've started teaching a lot of people HTML by showing
them something that has nothing to do with HTML, clap clap clap clap clap clap
clap...

~~~
cousin_it
Ease of adoption has a lot to do with HTML.

------
johnnybgoode
Yeah, this has annoyed me for a long time. I believe Opera comes closest to
this ideal. Actually, it might even meet all of the criteria already. It's a
shame I can't use it.

Edit: I think the only _complete_ answer going forward is to treat it like
suspending a machine. An open web page today is a running application with
state. It would have to be frozen when you go to another page (so that it
doesn't do stuff while you're gone), and resumed when you click the back
button.

~~~
derefr
In some ways, it _would_ be suspending a machine: if a textbox were really a
<canvas> controlled by Javascript, you'd have to suspend the Javascript VM
state in order to still have the text upon going back.

~~~
johnnybgoode
Yes, exactly, assuming you're using a JS VM. But I'm saying you'd have to
preserve the JS state anyway, because anything on the page could depend on it.

~~~
IsaacSchlueter
Not just JS state, either. What if I have a flash movie running? When you
middle-click a link on a YouTube video, the video keeps playing. You probably
don't want pages in your history to be downloading data, playing video, etc.
Ideally, you'd probably want it to start playing right where you _left_ it
when you click back.

What about if the thing in my history is a 1gb video file, and I type
"gmail.com" in the address bar. I have Firefox set to remember my state
between sessions, and I rarely close my gmail tab. So, that video file might
stay in my back-button history for months. Is it reasonable to expect it to
freeze the video player's state and keep hold of that forever, every time the
browser starts up? That'd probably suck.

So, the author's suggestion isn't _quite_ perfect. It's close, but misses some
important edge cases, and misses the point of why this is very hard to do
right.

------
damovisa
The author seems to be completely ignoring the fact that sometimes navigation
SHOULD be one-way only.

If the link or button you've clicked on makes a change on the server that
affects that page, it might not make sense to display the old page when you
hit Back.

For example, you were on the edit page of a list of messages you want to send
to another user on the site. You finished making changes and clicked "Send".
Now you’re on a page with a message saying, "Messages Sent!". What do you
expect when you click the Back button?

1\. The edit page with the list of “pending” messages that have actually
already been sent? 2\. The edit page with an empty list of messages or the
original messages but now with a “sent” status?

I’d argue that the second option is far less confusing for a user, but that’s
not what you’ve suggested should happen.

And what happens if you click Send again? In the first case, you could send
the same messages again, or maybe the server will reply with, "I don’t know
what you’re talking about - those messages are already sent". There’s no way
for a user to know!

Caching is all good and well, but sometimes you really don't want a page to be
cached. That's why there are headers for caching...

------
ekiru
As I hadn't ever really noticed this problem, I decided to see what would
happen if I hit the back button in firefox after disabling my wireless
adapter. After reading the article, I was quite surprised that it went back to
HN perfectly. I also tested it with a longer back/forward history. In one
attempt, I was able to back/forward through seven pages(that's all that I had
been to in that tab at the time) without having internet access. Is there some
subset of web sites for which this wouldn't work properly, as the author seems
to be saying? Is the subset of scenarios in which the back button works only a
small portion of typical scenarios?

~~~
lincolnq
I think if Firefox knows you're online, it will hit the server (sending e.g.,
If-Modified-Since), but if you go offline, it can tell and puts itself in
offline mode, where it browses from the cache only. You can do the same
experiment just by doing File - Work Offline.

~~~
ekiru
Ah. Of course. I didn't consider that possibility. Now I've tried back/forward
while connected to the internet and looking at Network Usage in Activity
Monitor. I noticed that most of the times when I hit back/forward, there was
no network traffic. I expect most of the traffic I did notice was either due
to cache refreshes or due to other apps(probably mostly Thunderbird) I have
running.

------
swolchok
Great, now my browser can use even _more_ memory! I suppose that could be
mitigated if there was an option for the number of pages to hold open for the
back button this way for each tab and window.

~~~
JacobAldridge
Yup - if I want to come back here, I'll use a new tab. If I don't, click
through, and it's gone forever (not just 'hidden' in memory on my noticeably a
slower machine).

What's that - I need to go back? My fault, I deal with it, I'm not paying
someone $1000 to fix my stuff-ups.

------
tkiley
This article singles out Safari on the iPhone, saying that it supports "tabs".
Ironically, iPhone Safari's "tabs" behave exactly like this broken back button
behavior -- I've noticed that often when I switch back to an old tab on my
iphone, the page is often refetched (losing my position and any form content)
because it was unloaded while I was browsing on another tab.

~~~
dchest
That's because iPhone has only 256 MB of RAM and no virtual memory.

~~~
dchest
Sorry, only 128 MB of RAM.

------
petercooper
I agree with what they've said and I wasn't going to comment but.. I clicked
back to come back to Hacker News and it was _instant_. Like, not even 100ms to
do a modification check or anything. Bam. It's there. Perhaps this is a Safari
4 beta thing?

~~~
seabee
No, Firefox is just the same. It's really a web server thing - there is such
thing as 'caching', although OP seems to want to override such directives for
all pages and have them all cached.

------
pieter
My main gripe with 'back' in Safari is the keyboard shortcuts. I can press the
back button to go to the previous page, I cab press it with command to open it
in a new tab, I can press backspace to go to the previous page, then why can't
I press command backspace to open the previous page in a new tab?!

~~~
username
and on Macs, it costs $20 for drivers to use the back button on mice without
vendor software.

------
zouhair
I kinda dislike when people talk about things as they know something about it,
while they know squat.

And get rid of the pictures, it's annoying.

~~~
dchest
Users don't need to know anything about how things really work to complain
about usability problem. This is actually one of the most useful feedback
developers can get.

------
lucumo
_> I’d even say the reason tabbed browsing is so popular nowadays is actually
because back and forward are broken!_

Oh, come on now. The reason tabbed browsing is so popular, is because you can
work on several apps and websites at the same time.

Please make your points without making stuff up. It's annoying.

~~~
DLWormwood
> The reason tabbed browsing is so popular, is because you can work on several
> apps and websites at the same time.

Close, but not quite... Before tabs, you could still have multiple pages open,
but they each took up a window. Tabs are simply a streamlining of the multi-
window process. (And Chrome actually makes efforts to blur this distinction.)

------
brown9-2
This author has a really strange concept of what the "back button" should do -
probably very different than what most developers (this crowd?) would think.

------
quoderat
I tried to hack Firefox to make this work correctly, with only limited
success. Does anyone have the answer?

------
edw519
"Let me demonstrate how the back and forward buttons should work. You can do
this at home.

Click this link.

That should have opened in a new window (or tab) for you. And if you’re back
here now, you’ve switched windows or tabs, correct?"

Fail. It opened a new window with a page I had _never visited before_.

Of all the interpretations of the back button, I'm pretty sure that's not one
of them.

~~~
3pt14159
I think you missed the point.

He said "click here (insert random link)" then knowing that we would all ctrl-
tab back to the original article he was showing how backing up SHOULD work.
I.E., bringing you to right where you were previously and doing it fast,
without reloading the page.

