742264 - Submitting form with a target name that exist in other windows cause problem

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect)

Description

[Michał Lipiński]

Attachment: bug_target.tgz

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Hello,

I found a bug in my opinion it's may lead to some security issues.

Attachment test case 5 html files and 1 js. I'm running all on local web server.

1. Open index and click in link, this will open a window with some name assigned. Do that again, we have now 2 windows with similar content.
2. One should have name similar to w1333541595001_1  and second one w1333541597824_2.
3. In window that name ends with _2 click on open new window link to get 3rd window with a form.
4. Form will have a target with name of frame that exists in both windows, click submit (content show parent window name).
5. * Fail * submit goes to first window not to second one, which is a parent of this window. If submit will return some JavaScript I'm able to manipulate JavaScript data.

Tested against:

FAIL:
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19
Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27
Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C)

OK:
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19


Actual results:

Submit goes to first opened window not to second one, which is a parent of this window. If submit will return some JavaScript I'm able to manipulate JavaScript data.


Expected results:

Submit should go to frame in parent window not the first opened that contains frame with requested name.

Comment 1

[Michał Lipiński]

Additional info:

Just noticed weird behaviour if all of these windows will be open on tab, code works as we expect.
Tested by passing empty string "" to window.open

Comment 2

[Boris Zbarsky [:bzbarsky]]

The relevant part of the spec is at http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name and says:

  If the given browsing context name is not _blank and there exists a browsing context
  whose name is the same as the given browsing context name, and the current browsing
  context is allowed to navigate that browsing context, and the user agent determines
  that the two browsing contexts are related enough that it is ok if they reach each
  other, then that browsing context must be the chosen one. If there are multiple
  matching browsing contexts, the user agent should select one in some arbitrary
  consistent manner, such as the most recently opened, most recently focused, or more
  closely related.

I believe our arbitrary consistent manner is that after searching the window the form is in we search windows in the order they were opened in, and within each window tabs in the order they were added.

At the moment, the "related enough" condition is always true, and there are existing bugs covering that, I believe.  At first glance this looks like a duplicate of one of those bugs.

There shouldn't be any security issues here, since this is all same-origin, so the same effect can easily be achieved manually via script if the page wanted to.

Comment 3

[Michał Lipiński]

Thanks for Your reply Boris,

It seems to me that the details of these behaviors are not consistent, since passing empty string as 3rd parameter (WindowFeatures) cause that window are opened on tab and order is different to "windowed" mode.

Tab mode:
1 <- 2 (request goes here) <- ...

Window mode:
1 (request goes here) -> 2 -> ...

I understand that probably inspiration for implementation is from IE, but I believe that "other" way is better, it's more intuitive and more "expected to be".

Comment 4

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I believe "consistent" just means that it needs to be consistent each time the steps are performed (as in, not a random number generator but a deterministic algorithm).  The exact heuristic used is explicitly left up to the browser in the spec.

Comment 5

[O. Atsushi (Torisugari)]

Bug 277972
?