Back and forward buttons in an iframe

Question

Use the window.history object.

// For the current window
window.history.back();     
window.history.forward();

// For an iframe's window
iframe.contentWindow.history.back(); 
iframe.contentWindow.history.forward();

or

iframe.contentWindow.history.go(-1); // back
iframe.contentWindow.history.go(1);  // forward

https://developer.mozilla.org/en/dom/window.history

Update for 2017: There is no way whatsoever to do this if the origin of the iframe content is different from the origin of the enclosing page - unless you control the content at the remote origin and can have it accept postMessage events. If the origin is the same, the older answers still work.

If this is in a WebView within an application you control, you can also set up a hook native side to control this.

Button within frame:

<input type="button" value="Back" onclick="history.back()">

Button within parent frame:

<input type="button" value="Back" onclick="frame_name.history.back()">

Thanks everybody for your valuable pointers :-) I've managed to start from your suggestions and build on them a little further.

I have a webpage that has two vertical frames: a narrow column on the left for a menu bar (frame name="menu"), and a main window on the right (frame name="main"), spanning most of the width. I.e., the index.htm contains just a frameset across the whole surface. Now... to address the general "back" navigation problem in my simple frameset, I managed to use Pavel Strakhov's suggestion with input type=button - only I had to elaborate the DOM path a little further. As I have the button in the "menu" frame on the left, and the content to be navigated happens in the "main" frame on the right, the two frames are siblings, rather than a parent vs. child. Thus, in my case, I had to traverse one level up in the hierarchy, before I was able to refer to the sibling frame. As a result, in my case the button element reads

<input type="button" value="Back in the main frame" onclick="window.parent.main.history.back()">

or you can refer to the frame by ordinal index (zero-based) in an array, rather than by name:

<input type="button" value="Back in the main frame" onclick="window.parent.frames[1].history.back()">

I have also noticed that the whole 'onclick' property can be strapped onto pretty much any other visible element, such as an anchor/href (A), a DIV or a P. I've tried those as well, to make the "back" button look more like the rest of my menu, but ultimately went back to the crude "buttonish" look and behavior, to make the button more obvious / prominent / distinct. It looks raw but it works best.

Actually in my case, windows.parent actually refers to the top frame - so there's another way to refer to my frame called "main" and tell it to go back: onclick="top.main.history.back()" . Or, apparently, onclick="top.frames['main'].history.back()" .

And then I found out, that it still doesn't work reliably. Quirks discovered so far:

• in Firefox around v42, if you go back and then use the browser's "forward" button, several more URL clicks down the road you can get funny results: sometimes the history.back() function in a frame will result in a history.back() on the top frame, for no apparent reason.

• in Firefox around v42, sometimes the browser's own "back" button results in per-frame history.back(), rather than a top-frame history.back(), for no apparent reason (= inconsistent behavior of the native "back" button)

• regardless of the browser make and version, some websites apparently clear the history of their base frame on site load. If you load such a site in a frame, the per-frame history.back() does nothing.

This is possibly another reason (apart from homogeneous styling) why hardly anyone uses the good old HTML frames anymore. The resulting behaviors are not very deterministic / foreseeable / obvious to the user. This is probably why webmasters prefer fixed columns, implemented by tables or by more modern means. Or perhaps it's just because everyone uses a CMS nowadays anyway.