Broken Browsers Part One
May 13, 2009 on 4:40 pm | In New Features, Promotions, Rants by Josh Jones | 70 Comments
Web browsers have been around for a pretty long time now.
Web browsers have been broken for a pretty long time now.
Bring on the rotten tomatoes, but I still predominantly use Internet Explorer because it is still the least broken browser when it comes to one of the most important features for me:
The Back Button!
(and forward too!)
I cannot understand why, after zillions of versions and dozens of years, no browser implements forward and back correctly.
It’s like the FIRST feature web browsers even had!
What’s Broken About It?
It’s simple really… what do you expect to happen when you click back (or forward)?
You expect the web browser to immediately display what you were looking at before your last click.
What actually happens?
Sometimes you get a “cache expired” message. Sometimes you get a dialog window asking if you want to re-post to display the results again (ahem, Firefox). Sometimes you get sort of what you last saw, but it takes a second while it connects to the Internet and gets updated with new content. Sometimes everything is the same except that the big text field you had typed your blog post into is now EMPTY! And sometimes, yes sometimes, it works exactly as it should.
Google Too
I kinda like Google’s new browser Chrome. It’s fast and lightweight. But, I also can’t stand it because it doesn’t seem to cache our web panel or intranet pages at all!
Believe it or not, every once in a while our panel is just a weeee bit slow.. and if I use my back or forward buttons as I navigate around, those teeeeeeeeeeensy delays can add up! All the unnecessary page loads probably aren’t doing us any favors on the server-side either!
Google’s apparently making a big push for Chrome soon, including TV ads etc… but before they push too hard, I wish they’d fix their back buttons!
And Here’s How
The craziest thing about all this is, fixing it would be incredibly simple! In fact, I’ve already worked it all out!
Let me demonstrate how the back and forward buttons should work. You can do this at home.
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?
Ta da!
That’s it! That’s exactly how the back/forward buttons should work! See how FAST it was to get back to this page? See how you were scrolled to EXACTLY the same place you were before? See how you didn’t even have to be on the NETWORK to continue reading this post? See how you didn’t get any pop up warnings or expired CACHE messages? See how you could switch back to that other window (like going FORWARD) just as easily?
Internally, every time you click a link, the browser should handle it exactly the same no matter if you are opening a new tab, a new window, or staying in the same window.
The only difference when you click a link “normally” is it shouldn’t add a “new tab” to the interface … it should put that “new tab” in your back history!
I’d even say the reason tabbed browsing is so popular nowadays is actually because back and forward are broken!
Internet Explorer has always done the best (though not perfect) job with this; it’s probably why they were the last to add tabs.
It’s the main reason why I still use it… honestly, I’d switch away if there were a single browser (or a browser plugin?) that handled it right.
In fact, if somebody can either fix an open source browser to behave like this (or make a working plugin), DreamHost will pay them $1000!
More formally:
The first person to release a plugin for firefox or chrome that does this should post their submission in the comments.
The plugin should make it so that when you click “back” or “forward”, it behaves EXACTLY as though you just switched to an open tab/window with that content in it (though of course visually you stay in the same tab/window).
As for how many pages to keep “open” in the back/forward history, it should be as many as it can, dropping them out in order of oldest to newest as it needs to due to memory constraints.
(Oh yeah, you know what browser would benefit the most from this? Safari on the iPhone! It seemingly does NO caching, even though because of its slow connection/processor it needs it the most! You can’t even fake it with tabs because there’s no way (that I know of?) to “open link in new tab”. It supports tabs though (up to eight), so it should be able to keep at least eight back/forward history pages in memory too!)
Speaking of Prizes
Just a quick reminder that our API contest is still going strong with a due date for contest entries of May 31st!
The prizes are as follows:
Grand Prize: $5,000
1st Place: $2,500
2nd Place: $1,250
3rd Place: $500
4th Place: $750
All the entries so far are up on the wiki, and the winner of the April 30th “early-bird” contest ($2000 to the best app done by April 30th) is…
It’s a Twitter interface to the DreamHost API!
It’s simple, it works, it looks nice, and it has the whole CRAZY INSANE SUPER HYPE BANDWAGON going for it to boot!
But don’t worry everybody else, there’s a lot more prizes to be won, and it’s still not too late to enter now!
We’ve recently added a test account and lots of new functions, so check out our API documentation and submit your entries over here!
70 Responses to “Broken Browsers Part One”
Categories:
Archives:
- November 2009 (3)
- October 2009 (1)
- September 2009 (3)
- July 2009 (1)
- June 2009 (3)
- May 2009 (3)
- April 2009 (4)
- March 2009 (2)
- February 2009 (3)
- January 2009 (3)
- December 2008 (3)
- November 2008 (4)
- October 2008 (5)
- September 2008 (2)
- August 2008 (5)
- July 2008 (2)
- June 2008 (3)
- May 2008 (6)
- April 2008 (2)
- March 2008 (3)
- February 2008 (5)
- January 2008 (7)
- December 2007 (3)
- November 2007 (3)
- October 2007 (5)
- September 2007 (3)
- August 2007 (4)
- July 2007 (4)
- June 2007 (7)
- May 2007 (3)
- April 2007 (3)
- March 2007 (8)
- February 2007 (4)
- January 2007 (6)
- December 2006 (5)
- November 2006 (2)
- October 2006 (4)
- September 2006 (4)
- August 2006 (5)
- July 2006 (3)
- June 2006 (3)
- May 2006 (5)
- April 2006 (6)
- March 2006 (7)
- February 2006 (6)
- January 2006 (8)
- December 2005 (7)
- November 2005 (5)
- October 2005 (8)
- September 2005 (19)
- August 2005 (11)
- July 2005 (4)
Other Sites
- DreamHost Status - An off-network page for all DreamHost Announcements! (Not as silly as this blog.)
- DreamHost! - The host behind the blog.
- Forum - Discuss DreamHost and web hosting!
- Web Control Panel - Manage your account.
- Wiki - On DreamHost and web hosting.
Powered by WordPress. Pool theme by Borja Fernandez, modified by DreamHost.
Like WordPress? Consider attending WordCamp LA.
Entries and comments feeds.
^Top^
May 13th, 2009 at 5:03 pm
Opera does this already, and it has for a long time. It’s the main reason it’s my primary browser.
May 13th, 2009 at 5:26 pm
Well, Firefox has gotten pretty good about this after they implemented the bfcache back in 1.5 (or was it 2.0?). I almost never hit the problem that you describe, except in cases where caching is disabled, either because the server explicitly says so or because of HTTPS (that’s the price of security, I supppose). And I think that’s what’s really tripping you up.
And the biggest complaint about the bfcache? Memory. For people with dozens of tabs open and a dozen history items per tab, that adds up to a lot of memory taken up by the bfcache, so for 3.x, Firefox started to trim the bfcache more aggressively. Your proposal of basically storing the entire tab will be even more memory-intensive than the bfcache. Don’t be surprised if, when such a feature is added, people start to scream bloody murder over the memory usage. It’s all about tradeoffs, I’m afraid…
May 13th, 2009 at 5:40 pm
I don’t get it. Perhaps because Safari on the Mac has always been fine with this.
May 13th, 2009 at 5:59 pm
Opera has done that for about 10 YEARS. Where have you been, Josh?
May 13th, 2009 at 6:17 pm
On the iPhone you just need to hold your finger on a link for a couple seconds and then a menu comes up. Touch the “Open Link in New Page” button to open the link in a new tab.
May 13th, 2009 at 6:21 pm
Re: iPhone. It does have a cache, but it is quite small (cf 128 MB memory and no paging to disk). Try going back from one small page to another, then it works.
Also, try loading up 8 tabs in Safari Mobile. Go back to the first, you’ll see the thumbnail, but open the page itself and you’ll find that only the thumbnail was cached, not the page. Visit some heavy pages, and it will start dropping the thumbnail caches too, giving the white page screenshot you posted.
May 13th, 2009 at 6:23 pm
The web browser for this when it has very little to do with this. The browser 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. And guess what, it works *exactly* the way you want in *all* browsers because I’ve set the headers 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). If you’re getting pop-up boxes from Firefox, it’s because the web site owner hasn’t given it enough information. If you’re getting different results from IE it’s probably doing something incorrectly (this is IE after all).
May 13th, 2009 at 6:24 pm
So, how many pages back for each tab do you want?
B/c that’s the multiplier on the memory footprint of the web browser.
May 13th, 2009 at 6:58 pm
Hmm, I just tried Opera and it doesn’t do it quite right. I’m pretttttty sure Safari on the Mac doesn’t do it either. Just try going back and forth between a large page and another large page and watch the little delay while it re-renders the page. Now open both pages in separate tabs and go back and forth.. it’s a bit quicker right?
I guess maybe what would be ideal memory-wise is if the browsers kept the last 8 or so pages in a completely rendered state, and then beyond that it just kept some kind of state information (url/source code/location on page/javascript values/etc..) to re-render pages older than that. And as you start to back up it starts to render in the background the older pages so they’re ready when you get there. Kinda like those online photo albums that download the next picture while you’re still looking at the current one..
Ah yes, there is some caching settings the server can send back to the browser, but I guess the issue is, no matter WHAT the cache settings are that are being set, the behavior people really want when they click back is the same behavior as clicking “open in new tab” and then switching back to your original window. Really, if somebody wants to get a new version of the page they can reload! Or nowadays the website owner could use ajax to refresh just the updated info for them if they REALLY want..
josh!
May 13th, 2009 at 7:28 pm
I’m not sure I agree with you on this one.
Sure, when you’re just browsing a web site, the back and forward buttons should really do what you describe. But what about if the result of your last click was that something changed?
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 “Save”. 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!
There are certainly better examples, but the important point is that sometimes navigating to another page SHOULD be a one-way operation. The Back button SHOULDN’T work as you describe.
Damian
May 13th, 2009 at 7:29 pm
Apologies – the description in my last post should have said ‘You finished making changes and clicked “Send”’ rather than “Save”
Damian
May 13th, 2009 at 8:22 pm
That’s it! That’s exactly how the back/forward buttons should work!
That’s why there are tabs & I use it frequently.
May 13th, 2009 at 9:13 pm
I think Josh wants a ’start over’ button instead.
May 13th, 2009 at 9:19 pm
Check out:
http://plugins.jquery.com/project/historyevent
I’ve used this JQuery plugin on my site with great success.
May 13th, 2009 at 10:00 pm
That’s a damn good point and I’ve never even thought about it before.
I can always refresh if I want it refreshed. I hate how it kills my scroll position and text boxes. I hate even more that sometimes it does have it cached and I can never rely on it to do one thing or the other.
May 13th, 2009 at 10:38 pm
IMO there’s another major problem with browser’s Back buttons.
When you open a link in a new tab, that tab’s back and forwards buffers are empty (from memory this is the case in the Firefox, IE and chrome — i can’t check at the moment).
But I think you should be able to click Back to go back to the page you opened the link from (and keep on going back beyond that). The fact that you’ve opened this link in a different tab should IMO be immaterial. I get frustrated all the time by this inability to go back like this.
May 13th, 2009 at 11:55 pm
I’d worry about the extra memory usage – especially on iPhone. If I leave a bunch of big pages open in Safari, and then try to play a game, it can lag or even lock up and kick me out due to insufficient memory.
Lally Singh said it well: You’re multiplying the amount of memory used by the size of the stack of tabs maintained in the history of each page.
@James C: “New tabs retain the session history of the originating tab. Links opened in a new tab won’t have a blank history, but one that is populated from the “parent”" – from the description of https://addons.mozilla.org/en-US/firefox/addon/1859
May 14th, 2009 at 12:16 am
I’m satisfied with the way Opera handles this. The short delay when ‘backing up’ to large pages is ok for me. The main point is there is no network activity, and my forms is still filled out.
It seems to be a limit on hove long the page is cached though. If a tab has been open for several days, the previous page will be downloaded again when going back. If this is a setting in the html or not, I don’t know…
May 14th, 2009 at 12:32 am
Damien and Wayne have it right. Caching relies heavily on what the server is telling the browser. You don’t want the browser to cache too aggressively — especially in web applications where the freshness of data is important.
That said, I feel your pain. In a perfect world, however, the answer to this problem is not saving the exact state of recently visited sites, but faster internet connections, smarter programming, and better browser technology. Not necessarily in that order.
We’re getting there. Google Chrome is a good first step — not that it doesn’t have its shortcomings. But it’s a godsend (especially for web designers and developers) because it is spurring competition amongst the browser vendors to be the best and brightest.
May 14th, 2009 at 1:40 am
@James C There’s a Firefox extension that fixes that; it’s called Tab History ( https://addons.mozilla.org/en-US/firefox/addon/1859 ) and I couldn’t browse without it.
May 14th, 2009 at 5:14 am
I can imagine this causing terrible problems with respect to billing credit cards, reserving hotel rooms, online bill payment and other stuff that should totally avoid back button shenanigans.
May 14th, 2009 at 6:34 am
My friend, you badly need to try out Opera :)
May 14th, 2009 at 7:32 am
By default, opera’s history naviagtion isn’t quite what you want. To make opera work like you want it to, under opera:config set “History Navigation Mode” to 3.
See http://www.opera.com/support/kb/view/827/ for more details.
May 14th, 2009 at 8:57 am
“Sometimes you get a dialog window asking if you want to re-post to display the results again (ahem, Firefox).”
This is exactly why I *love* using Firefox. When a website does not correctly implement the HTTP POST method, I *want* the option to resend.
May 14th, 2009 at 9:26 am
Hey James C,
You’re right about the losing the history thing on new tabs! IE actually does this as you describe and no other browser seems to!
In regards to people seeing something weird when they back up that shouldn’t be there, remember, what I’m describing can _already_ be done by simply clicking with “open in a new tab”. Although I’m not sure if there’s ever an option to “submit to a new tab”. I think also just refreshing the page (and THAT should prompt a “are you sure you want to re-post” when necessary) solves the problem.. I guess I sort of think most people know about refresh and would try that if they back up and see something they’re not sure is “fresh” anymore.
AND! Yay! That Opera user:config “History Navigation Mode” 3 seems to do it EXACTLY right! That’s what I’m talking about.. I may be off to Opera-land!
Still, if somebody can make a firefox and/or chrome plugin that does that, $1000!
josh!
May 14th, 2009 at 9:39 am
One man’s bug is another man’s feature.
May 14th, 2009 at 11:22 am
Try opera, I’ve never had a problem with it losing posts, cache warnings, etc. It *Just Works*.
May 14th, 2009 at 3:14 pm
@Josh
I am not sure how much trouble I will get for telling you this, so for the first time I am dropping my last name and my website, but in iPhone 3.0, you can open in a new window by holding down the link and click “Open in New Page”. This isn’t really a published new feature…
May 14th, 2009 at 3:38 pm
@Dan – Fuck I wish someone didn’t steal my iPhone while traveling. There’s going to be so many new features. I’m pissed.
I think _blank html flag should be taken away from everybody. If people want to open in a new window that’s there option. This is what screws things up. If it weren’t for that and some js stuff, the back button would always work. WC3 take _blank away.
May 14th, 2009 at 3:51 pm
Opera has done this basically as long as it’s been around. Unfortunately, they have changed the behavior since around Opera 9, to fall into line more with websites that want to be able to control whether the back button could be used or not.
Used to be, you could hit the Back button in Opera through secure sessions, and it wouldn’t check any of the refresh information. All content, even form content, was identical. Big security flaw as long as you weren’t careful, but I honestly loved the behavior. Opera is still the best available for Back-button usability though. It’s not perfectly reliable anymore, but it’s more reliable than the other browsers. Web designers frequently complained about it (and as a designer, I can understand the frustration), but dammit, as a user I want to be able to use the browser how *I* want to use it.
May 14th, 2009 at 5:52 pm
What is this Chirpbot crap? Just a relay to send commands from one place to another. It doesn’t DO anything. Obscene that this is enough to be a “startup” and that it won any money. (And no I’m not “JUS JELUS”. Merely sad that computer science has degenerated into such hype and trash since “Web 2.0″.)
May 14th, 2009 at 5:56 pm
It’s not (only) browsers who’s to blame here. Using ‘page based’ HTML as a platform, is also big part of the problem. The solution is to develop web sites like you would applications – centered around states – and not using HTML as your platform technology. Example: Submitting a form should not involve loading a new page. And it should definitely not generate a new history object. Using Flash (or even AJAX) as your platform, this is easily solved.
May 14th, 2009 at 6:16 pm
Josh is 100% correct and all these replies are superfluous (say that word out loud with the daffy duck lisp for best results).
Clicking between tabs was a superlative analogy, and is exactly how the forward and back buttons SHOULD work. So in short: shadup and get to crackin’ on that winning solution, nerds!
In a bit more detail: whilst we are smart enough to understand that inconsistent headers and so forth could cause the issues Josh describes, I’ll betchya $100 right now no forum or other web site shitz (that is plural on purpose …a playful nod to all our non english speaking friends across America), can go back and forth as gracefully as Josh’s tabbed example
Josh, I’m with you all the way. It’s time someone fixed the browser back/forward behavior. Just cache it like tabs do. Period.
GITERSDONE already!
TJ
http://www.tunajuice.com
May 14th, 2009 at 6:39 pm
I am floored that such a post was posted! Clearly, your a user not a developer who understands what is going on.
First off, one needs to understand that a URL is merely a location to a resource, there is nothing that states that that resource can’t change from view to view of that resource! This includes what could possibly be an entirely different form.. or when you enter the world of WEB 2.0 (which you seem to support so much) in web 2.0 world it is VERY common to have content swapping content in and out using AJAX without the URL even changing! Guess what that means! The browser never moved from the resource so you CAN’T FIX IT! Your back button will forever be broken until new web standards arise out of the W3C group to write a universal standard that dictates methods that a browser can request to a resource to display the previous view. Either that, or they need to make a standard Javascript hook where the browser informs the current page being viewed the back or forward button was pressed so that the javascript can use an AJAX call to request the server to display the previous view.. for which the application developer would be responsible for implementing!
Don’t believe me? Check out this product: http://www.icefaces.org. It’s a web 2.0 AJAX powered framework for java.. it’s about as Web 2.0 as you can get actually – full fledged incremental updates, a blocking thread to the server, server can PUSH updates to the user without the user requesting an action… and what else.. it’s very up front that becuase of all this AJAX WEB 2.0 integration IT DOES NOT SUPPORT THE BACK BUTTON!
WHAT? No… you wanted web 2.0 .. the developers gave it to you…sorry you lost your back button. Guess you’re stuck with web 1.0 if you want to keep it.
May 14th, 2009 at 6:40 pm
The above statement is so correct. I’ve done tonnes of lazy website developement. By that, i mean, simply letting crummy HTML forms do all work by redirecting you to the same page to update details. php and html forms just arent good enough to update displays.
Everything should be flash (which is annoying aswell in its own areas). or AJAX (which i love, so thats why im more into it than flash).
Fix this, and pages generate properly each time. Or update as you wish. Then there would be no need for firefox to warn you about hitting the back button.
However, it does warn you because you wouldnt want to hit the back button on a HTML page with a form submit that is some sort of payment. This could cause you to pay twice if firefox didnt warn you. So whoever wrote the script should make sure it works as its MEANT to. Or people could end up very unhappy with them.
May 14th, 2009 at 6:41 pm
You’d never see the “repost form data?” prompt if sites would handle forms properly. The Right Thing™ to do is to generate an HTTP redirect in response to a successful POST, so the browser issues a GET instead and the POST never makes it into the history.
http://en.wikipedia.org/wiki/Post/Redirect/Get
May 14th, 2009 at 8:05 pm
You know what I hate? When people decide that they know all about some problem and what’s wrong and how it should be solved, even though they obviously haven’t spent a second learning about the underlying issues. This whole post was a very long form of that, with pictures.
No, the Web isn’t perfect. When you’re viewing data that lives on a server a long way away, there have to be trade-offs between seeing data really quickly that might be out of date, or seeing the right data but having to wait a little for it. The architects of HTTP put a lot of effort into this, and caching in HTTP 1.1 works pretty well … when websites bother to implement caching correctly. Instead, too often the semi-skilled web programmers take the easy way out and just mark every page they serve as uncacheable (this is the default in PHP, for example.)
I haven’t looked at the HTTP responses coming from dreamhost.com, but I’ll bet that they aren’t doing caching correctly. Instead of trying to get people to mess around with web browsers (whose implementors really have thought about these issues) why don’t you have a look at what your own site is serving and try to fix it?
May 14th, 2009 at 8:09 pm
To follow up: I looked at a Dreamhost panel page (https://panel.dreamhost.com/index.cgi?tree=mail.addresses), and I was right:
Connection:Keep-Alive
Content-Type:text/html
Date:Fri, 15 May 2009 03:06:43 GMT
Keep-Alive:timeout=2, max=100
Server:Apache/1.3.37 (Unix) mod_perl/1.27 mod_ssl/2.8.22 OpenSSL/0.9.7e
Transfer-Encoding:Identity
The response doesn’t even have a ‘Last-Modified’ header, let alone an ‘ETag’. Your site isn’t bothering to even tell the browser whether it’s cacheable or not. Go and fix that before you whine about how lame the browsers are, okay?
May 14th, 2009 at 8:37 pm
All I know is that you guys are doing a real good job. I haven’t had any problems in the longest time. Thanks.
May 14th, 2009 at 8:50 pm
Talking about the browser breaking when hitting the BACK button, I thought it’s a security measure implemented by the browser? I know whenever I visit a bank site, most the time it does not allow you to click the back button. It’ll ask you whether you want to re-post to display the results again.
I thought it’s pretty normal.
May 14th, 2009 at 9:26 pm
@Ryan
Just because we’ve entered “Web 2.0″ doesn’t mean we should lose our back button. If you can’t write your AJAX app in such a way that you retain a user’s last actions (i.e. gmail), you need to consider how you are architecting your project.
Sure, the content on the last page might not be “fresh”, but the user clicked the back button, they didn’t click refresh. There is no reason to believe that the user requires the content to be refreshed. I’m with Josh on this one. I wouldn’t demand it be standard, but an option to enable “cached back browsing” would be useful.
May 14th, 2009 at 9:36 pm
# Sometimes you get a “cache expired” message.
So you want browsers to never clear the cache? I hope you’ve got enough RAM for that.
# Sometimes you get a dialog window asking if you want to re-post to display the results again (ahem, Firefox).
This depends on the server, not the browser. You can tell the browser to not re-post the content. Tell it to cache the resulting page or do a redirect away from the post page.
# Sometimes you get sort of what you last saw, but it takes a second while it connects to the Internet and gets updated with new content.
This depends on the server again. If IE isn’t doing this, then it is buggy. If I have a page that has an image that should only be cached for a few minutes, if you hit back after that time, I would expect it to refresh that image.
# Sometimes everything is the same except that the big text field you had typed your blog post into is now EMPTY!
I agree with this one, though it has bitten me in IE as well.
# And sometimes, yes sometimes, it works exactly as it should.
Or as you think it should :)
May 14th, 2009 at 9:39 pm
Ah, it looks like IE does get updated content when you hit back and forward. Go to msn.com in IE (or at least IE8). Click on any link in that page. Hit back. Notice that it is waiting for network data and that the ad is updated. Hit forward. Notice again that it is waiting for network data.
And so you want what?
May 14th, 2009 at 9:48 pm
Oh, and have you thought of the security implications? Say you were logged into your bank at the library computer. You then log out and walk away thinking you are safe. But if the browser cached it like you want, now anybody could come by and click the back button and they can see what ever you did in your account, plus account numbers and such.
May 15th, 2009 at 12:17 am
I was looking for this feature when I switched from Opera to Firefox and found that it was missing. I have since learned that the back button behaviour is a deliberate ‘feature’ of firefox – i.e. it is a correct implementation of W3C standards. As previously mentioned this is an issue of security and sadly a case where security is overruling usability.
May 15th, 2009 at 12:50 am
G’day Josh,
Hope all’s well at my favourite web hosting company… I’ve been all over this cloud stuff pretty much since we last spoke (though it wasn’t called cloud back then) and am currently working on a thing called the Open Cloud Computing Interface (OCCI). Couldn’t help but to notice that there’s some overlap with your PS products – maybe you want to add a bit of magic fairy dust in the form of OCCI and start calling yourselves a RealCloud™ provider? I see my last hot tip (get on Google Apps) worked out ok for you… maybe this one will too.
Say hi to Micah by the way… never got a chance to catch up last time I was in town unfortunately (this time last year).
Sam
May 15th, 2009 at 1:28 am
As others have already said: try Opera to solve this problem. Even after shutting down the PC for several hours Opera’s cache is usually still working when you restart! It can have many flaws but it definitely has more pros than cons.
May 15th, 2009 at 6:03 am
Josh, use Seamonkey! It backs and forwards to the same point no problem — and of course it is an all-in-one browser, editor, email, chat, blah blah blah blah. You don’t need nuthin’ else.
Regards.
John.
(Of course non-compliant webpages that fit only IE sometimes do not render 100% in SM — in those cases I just browse some where else.)
May 15th, 2009 at 6:14 am
Does this mean that Opera is a huge security risk? Is it going to be revealing account numbers and personal information even after I’ve logged off? THAT sounds worse than having to refresh an expired page.
May 15th, 2009 at 6:27 am
Don’t know if it’ll be eligible to the contest, but in firefox there’s a quick configuration to solve it.
Simply go to about:config, then change the value of browser.cache.check_doc_frequency from 3, the default, to 2, and restart firefox. So it’ll always check the before loading a webpage.
May 15th, 2009 at 7:00 am
I just did a (VERY) simple shell script to change the about:config in firefox under linux. You can get it at http://vitorbaptista.com/alwayscache.sh.
This way, the back/forward buttons works as you want.
May 15th, 2009 at 7:26 am
“Does this mean that Opera is a huge security risk? Is it going to be revealing account numbers and personal information even after I’ve logged off? THAT sounds worse than having to refresh an expired page.”
No, it means that if you have been on sites like that, on a computer that other people than you uses, you should always go to Tools -> Delete Private Data, and delete your private data. Very easy. And I prefer this way, since this way I get to choose when to do it! Sometimes I want to, sometimes I don’t.
May 15th, 2009 at 10:07 am
What if Dreamhost made their pannel work with google gears. Wouldn’t that also help speed things up?
May 15th, 2009 at 12:46 pm
if you just want to fix it for panel, use iframes (they don’t even refresh when you push the refresh button :)… ) just use script to navigate them and don’t add them to history, force update via script when needed. dont use form posts, for back will always ask you if u want to repost, use ajax instead (or if must, post in one of the hidden iframes, though that has more limits if goes cross domain), this way you can avoid the whole back-forward issue all together. As far as a plugin to do this, well it will be an issue, since crossing domains (yet keeping the previouse page data) would bypass most inplace security protocols.
Might as well just write a new browser… easiest way would be to just wrap a ie’s browser control with a shell and on every navigation create new browser window while hiding current…. this way your back and forth is just a chain of windows visible one at a time — this should work fine for static pages (memory will grow only as big as the page is) — downside, it will slow if those pages do anything (ex. script is on timer checking/doing things as most sites now days do and are very slow… and there is not suitable way to store the state of script or plugin on the page to cache it reverably onto disk)
here’s a bit of rant: mozilla’s (all of them) got much to go to catch up to ie’s extendability (and this i say not from liking MS, but from experience writing cross browser plugins) – just try making a plugin that you can move from one div to another without browser destroying and recreating it in between…. or try registering protocol handler just for the browser process that is displaying current page (and just that page) without having to install a component.. and crome is broken alltogether at the moment (at least thats what I call it if multithreaded plugin via npapi crashes it due to imcomplete support/improper code re-entry) limited support is no support :)
May 16th, 2009 at 8:28 am
I brows on a pretty old computer (10 yrs +) and it can’t handle most of the most recently published browsers and it is definitely annoying that when you press the back button that the browser doesn’t keep it in memory, but reloads the ENTIRE page, but I have found a browser that is tiny and keeps the pages in memory so previous pages just pop up instantly!!!! when I press the back button — check out the OB1 browser at http://www.offbyone.com/ It doesn’t always display the pages as they were meant to be shown, but super fast browsing on slow computers and a phenomenal back button are what really works for me.
May 17th, 2009 at 7:20 am
Hi Josh,
I do agree that something like this would be excellent and not necessarily resource heavy (these days), the cached information could be compressed making it manageable and still quick to decompress on the fly.
I think the important thing is to make it behave the way you want. Cacheing pages when you need them cached and semi (or not) cacheing them when YOU require (not when the browser thinks you require or even worse, when the website does) an update of dynamic content.
Of course, this is my very personal opinion and so I like the plug-in idea or make it an optional component in the various browsers.
But I wish to point you to the Symbian S60 browser (Browsing on a Nokia 6110 or N95 or similar). This does a very similar sort of thing where it literally caches the last page and it’s so important on a 3G connection where you can literally wait 20 seconds for google to load in some situations, or you may lose connection alltogether.
The only problem is, you can only go back once and going forwards again reloads the entire thing. But I think you’ll understand my sentiment with this example. My desktop is at least twice as powerful as my mobile phone!
Regards,
Stew.
May 17th, 2009 at 7:44 am
Good points. I never quite realized how broken it was until you mentioned it.
May 17th, 2009 at 12:10 pm
Thank you! I’ve always had a hard time explaining why I love OmniWeb, my favorite browser, but it implements back/forward perfectly—even retaining form contents. There are many other reasons why it’s my favorite (I’ve paid $29.95 for it several times over the years).
May 18th, 2009 at 5:39 am
Hi Josh,
i don’t see a deadline for this, is there any?
May 22nd, 2009 at 2:56 pm
Well, I believe that it just depends on if you want it that way or not. I think some people might actually want the page to refresh when they press the back/forward just so they’ll see the new data.
But you have a point there about the cache, I just think it’s an opinionated issue.
May 22nd, 2009 at 4:53 pm
Something else that needs fixing is offline browsing, I remember in the old days you could trawl through your history and reread stuff easily, even weeks and months back, but nowadays with so much dynamic content and ads and shit the feature is essentially worthless.
May 22nd, 2009 at 6:46 pm
Been using Opera and it works perfect for me.
May 25th, 2009 at 1:52 pm
As others have already said: try Opera to solve this problem. Even after shutting down the PC for several hours Opera’s cache is usually still working when you restart! It can have many flaws but it definitely has more pros than cons.
May 26th, 2009 at 9:29 pm
All the responses saying that “all sites should be in Flash” and positing AJAX as an answer to this problem are mad.
HTTP is essentially stateless. By design. The web would be a better place if everyone developed in a RESTful way ( http://en.wikipedia.org/wiki/Restful ) using the four verbs correctly (admittedly generally using POST rather than PUT on most installs).
As someone else said, PRG ( http://en.wikipedia.org/wiki/Post/Redirect/Get ) fixes many ills of form submission, but most people are too lazy to code this way.
Aside from this, Browsers still have a way to go to feel more responsive, and certainly could do more caching in the recent history to help.
+1 for Opera being about as good as it gets.
And please don’t use IE. You’ll only encourage them.
May 31st, 2009 at 8:50 am
Okay, I think I have something for you that I just finished coding.
http://www.savefile.com/files/2122189
Remove your old back/forward buttons and use these. Each time you click back, it sets the browser in offline mode, goes back, and puts it back in online mode. Same thing for forward.
June 9th, 2009 at 9:42 am
I like Chrome a lot. The problem with it is a lot of great plugins that work with Firefox and sometimes with IE don’t work at all with Chrome. Roboform being a big one. But I also use a lot of SEO plugins.
June 17th, 2009 at 7:25 pm
I’m actually a browser developer, and so perhaps can offer one view from the other side of the fence. The only reason that the back button cannot be fully implemented the way you describe is the onunload javascript handler. That’s it. The thing is, the onunload is supposed to run exactly once during the lifetime of a webpage, and that is when the user leaves the webpage. If you then later go “back” to that page, it may no longer function the way you expect because the onunload handler has done a bunch of cleanup. So browser developers have a choice: they can either support onunload, or they can implement back the way you want. I’m not going to go into the pros and cons of each side, but you should know that there is at least one valid concern when it comes to implementing the perfect “back”.
June 22nd, 2009 at 9:39 am
I agree. The back button really needs to work much better than it does. It simply needs to retrieve the cache. I cant think it would require too much memory to do this…
July 4th, 2009 at 8:38 am
There are many other reasons why it’s my favorite (I’ve paid $29.95 for it several times over the years).
July 4th, 2009 at 8:50 am
dont use form posts, for back will always ask you if u want to repost, use ajax instead (or if must, post in one of the hidden iframes, though that has more limits if goes cross domain), this way you can avoid the whole back-forward issue all together.