David Eyk Reporter
	Description • 12 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11

Steps to reproduce:

1. Visit http://google.com
2. Evaluate `window.top.name` in the Web Console. Should result in the empty string.
3. Visit http://biblegateway.com
4. Evaluate `window.top.name` in the Web Console. Should be "bgmain".
5. Visit http://google.com
6. Evaluate `window.top.name` in the Web Console. Should result in the empty string. Instead, results in "bgmain".



Actual results:

A non-empty value of `window.top.name` persists between sites.


Expected results:

The value of `window.top.name` should not persist between sites. :)

	David Eyk Reporter
	Comment 1 • 12 years ago

FYI, I'm submitting this bug in Chrome (sorry), but I've verified this behavior in FF 17 on both OS X and Windows.

	Alice0775 White
	Comment 2 • 12 years ago

relevant Bug 191807

	Alice0775 White
	Comment 3 • 12 years ago

I can  confirm the behavior in Nightly20.0a1 on Windows7.
And the behavior exists in at least Firefox1.5.

	David Eyk Reporter
	Comment 4 • 12 years ago

If it helps to understand why this bug matters, `window.top.name` is often used as a fall-back for localStorage, a method popularized by Remy Sharp (http://24ways.org/2009/breaking-out-the-edges-of-the-browser/). 

Aside from the obvious data-privacy issues if window.top.name is used in place of localStorage, Lawnchair.js (https://github.com/brianleroux/lawnchair) is a popular localStorage polyfill that unfortunately explodes when window.top.name contains non-JSON-encoded data (see https://github.com/brianleroux/lawnchair/issues/70).

	Alice0775 White
	Comment 5 • 12 years ago

The behavior of Opera12.11 and IE9 is as same as Firefox.
Google Chrome23.0.1271.97m is as same as the Expected results in comment #0.

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 12 years ago

The name is attached to the browsing context, not to a particular window.  See http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-name

We should perhaps implement the "reset when doing a cross-domain navigation" part, though.  That said, that part of the spec makes no sense when an <iframe name> is involved, so I'd sort of like for that to get sorted out before we start making changes, because implementing what the spec says right now would break the web.  Someone who cares about this should get the spec sorted out, please...

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 12 years ago

Ah, so the spec says to only reset the name on navigation if the browsing context is a toplevel browsing context _and_ doesn't have an opener.

Which is fairly silly, since it means you can bypass that protection easily if you're an attacker, but ok.  At least it's probably web-compatible.