views:

596

answers:

4

I've created a tool that is used with a fairly popular music retailer.

The tool provides an enhanced search feature (transparent last.fm results, no ads, no lameness, nothing creepy) and I've found the most useful and unobtrusive way to display the search is as a toolbar using the much maligned iframe. This allows users to load search without stealing the users focus.

Not being a particularly big fan of iframes I thought it would be trivial to add a “close this frame” (ala Google image search) link allowing users to quickly and easily regain control of their browser.

However unlike google, I doen't know what the location of the content in the iframe is (only where it started, via src).

So now I find myself in world of XSS and all the security related concerns.

Using Javascript I've added 'back' and 'forward' buttons with the history object called from links in the parent (when a user does a search the results load into the iframe, so the back button allows them to go back to the primary site after their done using/perusing the search results).

Is there any way to call the current location within the iframe and reload the page (now sans frames) to that location?

I've checked PHP $GLOBAL/$_SERVER variables to see I might get lucky. I understand that there are security concerns, but I don't see how this particular function would be any different then history.back() where the browser makes the call itself without 'notifying' my parent frame.

I know I can retrieve the src location from the iframe itself, but of course that presumes the user doesn't navigate beyond this page, and if they do they don't mind losing their current location and being redirected back to page called initially by the frame (...ah...).

It almost seems like frames are designed to steal windows with no means for gracefully 'breaking out' and preserving integrity of the users session.

No wonder people hate them. :)

+2  A: 

On Google image search when you remove the frame it functions as you currently propose, by returning to the original frame source. For XSS reasons, finding the current location shouldn't be possible, and if it was it would be considered a bug and fixed in subsequent browser patches, so it might not be best to rely on such a quirk if one existed. A way to elegantly break out without revealing location would be nice, though. This might be something you can propose to the HTML5 group.

Zach
A: 

Ya, but Googles solution only works by loading the original source of the frame (I think the links are even hard-coded?) so this doesn't really help users 'navigate away' from a frame if they do anything within the frame.

It just seems so silly (not the security, but the missing feature). It's all there.

history.back() history.forward() location.reload()

Are all location aware and allow actions called from outside the frame. All I need is to allow the reload to retarget and load directly into the window.

A: 

Not that it would really be all too helpful, but the closest you can come is detecting if someone actually left the original frame source page. When you navigate a frame the history object maintains entries, and if your original history length when the page loads is greater than the history length when someone clicks "Break out of this frame...", then you know they were browsing in the frame.

hal10001
A: 

I appreciate both you (hal10001) and Zach taking the time to answer. It appears I'm suck (as I suspected) because of the xss security concerns.

I suppose I could simply wrap all the content within a php based proxy, but that would clearly entering the creepy zone, not to mention the added latency and what-not.

I'll keep spinning the idea incase I do come across something sane and usable, but until then I guess I'll just use the slightly less freindly approach of promoting the original frame and wiping out their current location (and if they don't like I can revisit the iframe/toolbar situation.

Thanks again!