431835 - links in one frame, which are targeted to open in the other, open in a new tab

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

[Giedrius]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008041515 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008041515 Firefox/3.0b5

The summary basically says it all. It really is straightforward to notice the bug in http://www.ibb.lt I don't believe there is a bug in the HTML code, because I have tested it with a lot of other browser, and it worked fine, Firefox 2 included. However an older version of the frameset code works at http://www.ibb.lt/eindex.html . But using the same old code, with changed initial src tags of framesets produces the same incorrect behavior. I believe this may have something to do with frames sources being on different servers (my site uses several hosts)

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.ibb.lt
2. Press any link in the left frame
3. Observe the newly opened tab
Actual Results:  
A new tab.

Expected Results:  
Page opened in the right frame.

I have asked my friend who is running on Ubuntu 8.04 x86 to test the website, he got the same results as I did (on Ubuntu 8.04 x86_64)

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed on Windows XP. Regression range is:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1201460760&maxdate=1201462919
-> bug 408052.

Comment 2

[Collin Jackson]

Does this issue manifest on IE7 and Safari as well?

Comment 3

[Giedrius]

The page appears fine on IE7, aswell as IE6. I have no way to try it on Safari.

Comment 4

[Adam Barth]

Hum...  IE7, IE8 beta, and Safari 3.1 (PC) behave the same as FF3 for me (the links open in a new tab / window).  This appears to be because the left-hand frame is on a different domain than the main frame.  If you host the left-hand frame on the same domain, the links should open in the right-hand frame.

Comment 5

[Collin Jackson]

Safari 3.1.1 (Mac) also matches the FF3/IE7/IE8 behavior.

Giedrius, check your "Navigate subframes across domains" pref, you may have it on a nonstandard setting.

For the left-hand frame, try using the menu at <http://www.ibb.lt/menu.html> instead of <http://ibb.vdnet.lt/player/menu.html>.

Comment 6

[Giedrius]

Collin, I haven't changed any settings on any of my browsers. And I actually was unable to locate that preference, so I doubt that I had changed it.

More people using IE7 said that it works fine for them.

I really don't see any reason why the way tabs worked in FF2 should be different in FF3. If it works the same in IE8, then has some specifications changed or something? :/

Anyway I will try to move the menu.html to the www.ibb.lt server and I'll let you know the results.

Comment 7

[Collin Jackson]

(In reply to comment #6)
> Collin, I haven't changed any settings on any of my browsers. And I actually
> was unable to locate that preference, so I doubt that I had changed it.

You can find this pref on IE7 by going to Tools, then Internet Options, then Security, then Custom Level. The default level is "Disabled" but it can be controlled by group policy so your computer may have had a different default when you got it.

> I really don't see any reason why the way tabs worked in FF2 should be
> different in FF3. If it works the same in IE8, then has some specifications
> changed or something? :/

Yes: <http://www.whatwg.org/specs/web-apps/current-work/multipage/section-windows.html#security2>

Comment 8

[Giedrius]

Indeed the option was on "Enabled". Putting it to "Disabled" made IE7 behave like FF3.

I tried to move menu.html to ibb.lt, and just then I remembered why I had decided to have menu.html not in its logical place in the first place - menu.html has a "hidden" flash object, which allows music to play while viewing other pages of my website and is controlled from "Repertuaras" (or "Repertoire" in English part of my website), and since ibb.lt has whole 5MB of storage, all music is hosted on ibb.vdnet.lt by my ISP for free. It involves a lot of stuff to get my player to play music from a different domain.

I worked a bit on this issue and solved it. When I moved the rightFrame page to ibb.vdnet.lt, IE7 and FF3 started to behave in an interesting way (http://www.ibb.lt/index_old.html). The first few times you press a link in the menu, it displays in the right frame, and then a new tab opens.

Then I made a bit of a hack, which made me have an even more illogical file structure of my website. I created a hack.html on ibb.vdnet.lt, which contains the same code as index.html contained, only the frame sources are at the same host, and made index.html to have one big frame, which source would be the hack.html file and now my website works fine both on IE7 and FF3, but at a cost of horrible file structure.

I don't quite see what potential security risk is this new specification trying to prevent.

Comment 9

[Collin Jackson]

(In reply to comment #8)
> I worked a bit on this issue and solved it. When I moved the rightFrame page to
> ibb.vdnet.lt, IE7 and FF3 started to behave in an interesting way
> (http://www.ibb.lt/index_old.html). The first few times you press a link in the
> menu, it displays in the right frame, and then a new tab opens.

Yes, that behavior is by design. When the right frame is navigated to somewhere other than ibb.vdnet.lt, the left frame loses the ability to navigate it.

> I don't quite see what potential security risk is this new specification trying
> to prevent.

Here's a white paper that explains the change: 
<http://crypto.stanford.edu/websec/frames/>

Comment 10

[Lloyd Wood]

I really don't understand this new security limitation on framesets. If the aim is to prevent spoofing, shouldn't all framesets that cross domains fail to work?

Other cross-domain framesets I have under:
http://info.ee.surrey.ac.uk/Personal/L.Wood/spacesearch/
are still functional with Firefox 3, despite using a cgi on one server to spawn a frame from another (a search engine). What's the difference between these and
http://info.ee.surrey.ac.uk/Personal/L.Wood/jargon/
that I'm missing?

Comment 11

[Adam Barth]

If you're interested in the security restrictions on frame navigation, I'd recommend reading:

http://www.adambarth.com/papers/2008/barth-jackson-mitchell.pdf

or 

http://crypto.stanford.edu/websec/frames/navigation/

Comment 12

[Lloyd Wood]

Thanks, Adam. I've read your material, but am not further enlightened; your papers don't define what a 'child frame' or 'descendent frame' is, much less give examples with frameset code.

I've now gotten
http://info.ee.surrey.ac.uk/Personal/L.Wood/jargon/
working in Firefox 3 - contrast with
http://info.ee.surrey.ac.uk/Personal/L.Wood/jargon/index-old.html
which didn't work correctly. (Bug 469507 can probably be duped to this.)

However, I have no understanding of how I achieved this, or what the difference between the two framesets is in terms of increased security.

Comment 13

[Adam Barth]

Imagine that page A has two frames, B and C.  Both B and C are children of of A.  If B itself has another frame, D, then D is the child of B and a grandchild of A.  All the frames B, C, and D are descendants of A, and D is also a descendant of B.  If it helps, you can think of the frame tree like a family tree (the terminology should match).

The reason index-old.html doesn't work is because all the frames are in different domains.  The browser can't distinguish the navigations from an attack.  The easiest way to make it work is to put all the frames in the same domain.