This issue reported by bangpound here:
http://drupal.org/node/476004#comment-1643904

I don't remember seeing iframe pages in my browser history, though. Is that new? The iframe'd pages appear in my browser history.

Nope. It shouldn't. The framed document is loaded using location.replace() and this should not affect the browser history.

I'm guessing the browser history is affected when you submit a framed document or something similar. So I probably need to add something to the child window code to avoid this.

There would be 2 things to consider:

1) Navigation generated by following links that open inside the framed document. Here I could capture click events and replace them with location.replace().

2) Form submission. Here, the only way I can think of now would be to capture form submit events and replace them with AJAX requests where the result replaces the whole HTML document.

Caveat: If we do this, then it means the browser history will not be usable within the framed document. I guess this is better than affecting the parent's document history.

Thoughts?

Comments

markus_petrux’s picture

Another possible way to approach this:

3) Try to rollback the history when the modal frame is closed.

We could try to do this using the history.go(url) feature. We need to open the modal frame with a unique hash where we can do history.go(modalFrameUrlWithHash), then history.go(-1) that would return the history to the state where it was when the modal frame was opened.

That's the idea, now I don't know if this can be really done without affecting the UI. Maybe using a separate iframe where we could move the browser history back?

markus_petrux’s picture

Title: Navigation within framed document appears in browser history » Prevent child navigation from affecting parent's history

Better title...

gábor hojtsy’s picture

I think there could be cases when it is useful to have history for the modal frame. In the d7ux prototype use of this module, we need it to support history, so you can still use your back button. I think it is considered bad behavior to break the back button in such cases. But in the d7ux use case, we are taking over almost all of the screen, so the expectation is probably similar to if we'd use the whole window: to keep history.

gábor hojtsy’s picture

So to reword that, it would probably be good to make this a setting instead of wiring in something default.

markus_petrux’s picture

Yes, the browser history is important when we are interacting within the modal frame. In fact, the browser history would be an advantage compared to AJAX dialogs.

We need time to experiment with one of the approaches I posted above, or think about better ways to do it... once we can come up with a method that works, we may implement it as an option or not, depending on how well it works, I guess. :)

markus_petrux’s picture

Status: Active » Closed (won't fix)

Honestly, we've been using modal frame for some time now, and we haven't found any user reporting *real* issues with the browser history. So this is "won't fix", at least until we have a real problem.