49

Overview and original question

window.name is an interesting beast. MDN's description hints at the original intent:

The name of the window is used primarily for setting targets for hyperlinks and forms. Windows do not need to have names.

So, this means we can open the console in this window, and write:

var win = window.open('http://google.com', 'el goog');

...and then let it through the popup blocker, that should open google.com in a window named "el goog." I can't access the name property of win because of the same-origin policy, but if I open a console in the new window and type name, I'll get "el goog".

If I send the window back to the domain I opened it from (in this case stackoverflow.com), I can get the name property, and it hasn't changed.

win.location.replace(location.href);
win.name; // "el goog"

This means we can have a kind of cross-domain session store by setting the name property of a window.

If google.com had changed the value of window.name before the window was sent back to the original domain, we'd see the new value instead of "el goog." This could be used as a cross-domain data transport, similar in utility to JSONP or CORS.

I did a bit of searching to try to find more info, and apparently dojo thinks it's legit as a transport. Somehow, though, that doesn't completely reassure me. So my question is, are any reputable sites using window.name as a data transport? I'd think it would be easily spotted, because their docs would say something like "add 'callback' to the query string for JSONP, or add 'whatever' for window.name," but I've never seen anything like that. Has anyone actually spotted this in the wild?

Alternate question

It may be the case that nobody is really using this technique; if that's true then (as Rob W pointed out) the question above is unanswerable. So, my alternate question is, what are the problems with this approach? This might help explain why it hasn't really been adopted.

As I see it, there are at least two benefits to this approach over JSONP.

  • With JSONP, you trust a script from a foreign origin to run on your domain. With window.name, any scripts included by a malicious site would run on their own domain.

  • With JSONP, there is no way to pass in big data (anything too big for a URL), and no way to make an HTTP POST. With window.name, we can post arbitrary data of any size.

What are the drawbacks?

Example implementation

Here is a very simple example of a client implementation. This doesn't handle POST requests, only GET.

function fetchData(url, callback) {
    var frame = document.createElement('iframe');
    frame.onload = function() {
        frame.onload = function() {
            callback(frame.contentWindow.name);
            frame.parentNode.removeChild(frame);
        }
        frame.src = 'about:blank';
    }
    frame.src = url;
    document.body.appendChild(frame);
}

// using it

fetchData('http://somehost.com/api?foo=bar', function(response) {

    console.log(response);

});​

I've set up a fiddle to test it out here. It uses this script as a test server.

Here is a slightly longer example that can make POST requests: http://jsfiddle.net/n9Wnx/2/

Summary

As far as I can tell, window.name has not caught on as a data transport. I wonder if my perception is accurate (thus the original question) and if so, I wonder why this is the case. I've listed a few advantages that window.name seems to have over JSONP. Can anyone identify some disadvantages that might have contributed to preventing adoption of this technique?

More to the point, can anyone give me a solid reason why I shouldn't use winow.name as a data transport?

Didier L
  • 18,905
  • 10
  • 61
  • 103
Dagg Nabbit
  • 75,346
  • 19
  • 113
  • 141
  • @RobW something like "yes, the blahboop.com API will respond to requests with either JSONP or window.name..." where blahboop.com is something people actually use. Something to add some legitimacy to the idea. I'm pretty sure I can handle the implementation, but I think seeing a legitimate site using the technique might speak to reliability (at least the behavior would be less likely to be removed in the future) – Dagg Nabbit May 12 '12 at 22:32
  • Knowing that a certain site uses a technique does not make the method any more powerful / valid. Assume that the answer was "Google uses this technique". What gives? The question would be more *answerable* if it was phrased like "... Any pitfalls / possible issues?" – Rob W May 12 '12 at 22:43
  • @RobW I thought about that, but it felt like I was basically saying "why isn't anyone using this technique," and I wasn't sure if it was actually true that nobody was using it, so I thought I'd ask about that first. – Dagg Nabbit May 12 '12 at 23:21
  • In which browsers have you tested the feature, by the way? If you want to, I can test the feature in about 26 browsers (I have set up a VM containing these, see my latest question if you want to do the same). When every browser supports the feature, it *might* be useful. A possible drawback is that a whole document has to be rendered for each transpot, making the use of it more expensive than JSONP. – Rob W May 13 '12 at 20:58
  • @RobW that would be awesome, you can use the last jsfiddle link... I don't know how you'll test the form posting without some kind of server-side script, though. I can throw something together for that if you want, just let me know what language. – Dagg Nabbit May 14 '12 at 00:15
  • @RobW sort of OT (I didn't want to mess up your other thread) but I think that setup you have would really be ideal if you could test on OSX and linux as well... old versions of Safari on Mac are notorious for weird behavior, and on linux you have konqy, and weird outliers like epiphany. Might be cool to hook it up to the android emu too. I do wonder if all of these browsers handle `window.name` the same way, I guess it's completely unspec'd actually... certainly not in ES anyway, pretty sure it's not part of the DOM either. Maybe that's the real reason it's not being used? – Dagg Nabbit May 14 '12 at 01:04
  • All homepages in my VM are set to `http://10.0.2.2:8888/`, on which I run a Node.js server. All I need are the files for the set-up. As for the VMs: The aim was one VM which contains all browsers. I also have an OSX VM, and my main environment is Linux-based. I am aware of UI bugs with Safari on Mac, but I don't think that significant JavaScript differences exist. Also, I have just found a "wild application": [Facebook uses `window.name` for their login API](http://stackoverflow.com/q/8780368). – Rob W May 14 '12 at 07:33
  • Just tested: http://jsfiddle.net/NMdLU/1/ works fine in Chrome 1-20, Safari 3.2.3-5.1.5, Opera 9.00-12.00 and Firefox 1 - 12. In IE6, `attachEvent` has to be used to add the `load` event. After doing that, you will discover that `window.name` is not persistent when the location is changed by setting the iframe's src in IE 6, 7, 8, 9 and 10PP4. [This simple demo](http://jsfiddle.net/LKrEd/7/) shows that setting the SRC blanks `window.name`. – Rob W May 14 '12 at 14:12
  • @RobW thanks, this is really helpful, and the FB thing is reassuring. There must be some workaround for IE, I'll see if I can figure something out and report back. Maybe something with `history`. Are you sure `contentWindow` works in IE? In my latest fiddle (last link in the Q) I got rid of `contentDocument` and `contentWindow`, thinking it might not be supported everywhere. BTW the Safari bugs I was thinking of were things like XHR, ranges, and event weirdness... – Dagg Nabbit May 14 '12 at 21:03
  • @DaggNabbit can u please answer my related qeustion : http://stackoverflow.com/questions/19487729/cross-domain-using-window-name-double-onload-should-be-used ? – Royi Namir Oct 21 '13 at 06:51
  • 1
    Approach being used at http://www.thomasfrank.se/sessionvars.html – Brett Zamir Feb 06 '14 at 04:31
  • @DaggNabbit what did you ultimately discover about this approach? We're looking for ways to have 2+ browser extensions talk to each other in a scratch space before the DOM has been built (so we can't use a div on the page, for example) and window.name is looking like it might be an interesting contender... (I know many extension platforms have messaging APIs; we can't use it because the extensions won't know each others' addresses. We're trying to figure out how to pass addresses to one another.) – MrChrisRodriguez Jun 24 '14 at 20:47
  • 1
    @MrChrisRodriguez it sounds like this would work fine for what you're doing, but you might also want to look into [postMessage](https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage). – Dagg Nabbit Jun 24 '14 at 21:21

2 Answers2

6

window.name isn't particularly good as a transport, as (AFAIK) it doesn't fire any events when it's changed. As a result, an application which was trying to use window.name as a two-way communications channel would have to poll it for updates.

As far as sites that actually use it: I've never heard of any. There might be some, but I've only heard this technique discussed in a purely theoretical sense.

  • Funny, I was just thinking about the event thing. ISTM that something like `myIframe.onload = finishRequest; myIframe.src='somehost.com/api/?id=123'` should work fine... – Dagg Nabbit May 12 '12 at 23:16
  • I've added an event-based example to the question. Was that what you had in mind? Is there anything else you can think of that would make it not a good data transport? – Dagg Nabbit May 13 '12 at 01:26
  • @AwalGarg You can't send events to a window on another origin. –  Oct 30 '15 at 06:37
3

More to the point, can anyone give me a solid reason why I shouldn't use winow.name as a data transport?

While window.name can be a true saviour when it comes to transporting data accross domain changes, the reason it cannot be used as real universal data transport mechanism is due to the lack of an api to store and retrieve data. For example localStorage provides setItem, getItem. Such an api is necessary to abstract from how values are actually stored and to prevent format clashes (which would arise if different libraries running on your side would store in different formats).

As far as I can tell, window.name has not caught on as a data transport. I wonder if my perception is accurate (thus the original question) and if so, I wonder why this is the case.

Since window.name does not provide such a store/retrieve abstraction layer – as described in my point above – 3rd-party librabries cannot know which format to use when storing data in window.main and hence will never use window.main as it is unreliable. If you (i.e. your main program) were the only one reading from or writing to window.name you could decide to store data in json format and store/retrieve accordingly. But what if a 3rd-party library also wanted to store/retrieve something and it decided not to use json and instead go with another of the numerous serialization formats... this would accidentally break your json format and definitely cause trouble.

Felix K.
  • 14,171
  • 9
  • 58
  • 72