203158 - windows opened into tabs by middleclick or ctrl+click have no opener

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P5)

Description

[thm]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401

- This test fails when I Ctrl+click on the link to win011.html page.
Is there no calling window name in this case ?
- This test fails when I input the link in the address bar
Normal behavior I think, cause there is no calling window (i am the caller !)
- This test success when I click on the link to win011.html page.
The test is open in a new navigator WINDOW and it succeed.


Reproducible: Always

Steps to Reproduce:
1.go here :
http://mozilla.org/quality/browser/standards/javascript/tcmatrix/window.html
2.and ctrl+ckick win011.html link 
3.

Actual Results:  
Description  	Read window.opener null
Pass  	        failed	
Bug Number  	Bug report required
Actual Result  	null
Expected Result [object Window]

Comment 1

[Boris Zbarsky [:bzbarsky]]

> - This test fails when I Ctrl+click on the link to win011.html page.
> Is there no calling window name in this case ?

That's correct.  Over to XP apps to decide whether we want to try and set
window.opener there....

Comment 2

[Stefan [:stefanh]]

Testcase needs to be updated anyhow --> blocking 142649

Comment 3

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

Bug still there.

When using the URL property of this bug, it fails with:
*simple click: same tab
*Ctrl-Click: new tab
*Right click + 'Open Link in New Window': new window !

The JS.C. output is
[
Error: window.opener has no properties
Source File: http://mozilla.org/quality/ngdriver/suites/javascript/win011.html
Line: 41
]

In the meantime, who can do the following to be more precise ?


In <http://mozilla.org/quality/ngdriver/suites/javascript/win011.html> source,
replace "Bug report required" by "Bug# 203158".

Comment 4

[Serge Gautherie (:sgautherie)]

Addition to comment 3:

In fact, I get the error (line number can change a bit) on the URL properties
for all BugZilla bug reports, not this one only.

Comment 5

[Serge Gautherie (:sgautherie)]

Actually, the current bug seems very much to be a duplicate of bug 138402.

Shouldn't the former be marked as such, and the latter reopened ?

Comment 6

[Fabian Guisset]

I added a bug number to the testcase, so that's ok. Slightly morphing this bug
as bz suggested. (see comment 1)
XPApps guys: should ctrl+click set window.opener?

Comment 7

[Serge Gautherie (:sgautherie)]

Removing 'blocks bug 142649':
The testcase part is handled in bug 138402.

This leaves comment 6:
Should window.opener be set in such a case ?

The question might apply to 'window.name' in bug 47280 too ??

Comment 8

[Bradley Chapman (not reading bugmail, still gone but not forever)]

This is a partial dupe of bug 263844. CC'ing danm for his views.

Comment 9

[Dan M]

Yes and no. This is the older version of bug 263844 that we were talking about
in bug 172962 comment 174 - 183, and bug 263844 comment 10. It's the same issue
really, but the code involved is very different. This bug deserves to remain
independent because 263844, being more visible circumstances and involving code
much easier to fix (if you ignore the crashes in my first attempt :)) will
certainly make it into Firefox 1.0, and this one promises to remain a problem
for a while longer.

Comment 10

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Fair enough danm - the thing which made me say that was the reference to
window.opener when opening tabs. Admittedly, it's a slightly more restricted
version of what you were trying to accomplish with bug 263844, but I figured
that the codepaths might be contiguous and easily dealt with.

Comment 11

[Asa Dotzler [:asa]]

too late to go digging into this for 1.0

Comment 12

[Jesse Ruderman]

This bug is invalid.  window.opener is only supposed to be true when the
window/tab was created by window.open(), not when it was created by the user. 
See bug 138402 comment 3.

Comment 13

[Dan M]

I agree that this bug is questionable territory, but I disagree that it's
outright invalid. Bug 138402 comment 3 isn't precisely correct (Mozilla and IE
both also set the opener for target="_blank" links that don't invoke
window.open), and shouldn't be interpreted too broadly. It's more about user
gestures than underlying code. It's a question of whether a middle-click should
be understood to generate a different kind of window than one generated by a
left-click. I think it should not be.

Comment 14

[Jesse Ruderman]

Tabs opened by middle-click are most similar to windows opened by shift+click. 
Firefox doesn't set an opener for shift+click, but IE does.

I think Firefox's behavior of omitting the opener for user-created windows and
tabs is better. If I middle-click a link from a trusted web site to an untrusted
web site, the untrusted web site shouldn't be able to use opener.location.href=
and change the contents of the first tab.

Comment 15

[Dan M]

> Firefox doesn't set an opener for shift+click, but IE does.
That's probably a bug. The same bug, really.

There are cases where the window doesn't work quite right if you omit the
opener. I can't come up with a good live example right now but say middle click
on a "Beta - what's this?" link commonly in the upper left or upper right of
www.amazon.com. The resulting window has a "close this window" button that
doesn't work because of this bug. That's a trivial example and I don't have a
nontrivial one that works with middle-click (though I could name several if bug
138198 were fixed).

Personally I think behaviour most compatible with precedent "DOM 0" behaviour
and handiest to the user is a compromise between your proposal Jesse and simply
always setting the opener. I'll become more interested when someone steps up to
fix this bug :) By the way the cross-domain scripting scenario mentioned in
comment 14 isn't a concern special to middle-click.

Comment 16

[Jesse Ruderman]

For non-javascript links that are middle-clicked, giving the new tab (or window)
an opener would allow the opened page (or any other page later loaded in that
tab) to do two things it shouldn't be able to do:

1) Close the new tab.

2) Cause the old tab to navigate away from the page with the link.  (For
example, a site you reached by clicking a link in a Gmail message might load a
page into your Gmail tab that spoofs the e-mail, and then spoofs the Gmail login
page when you click anything.)

It's true that malicious sites can already do those things if the user
left-clicks a target="_blank" link, but IMO Firefox should not extend those
security holes to cases where the user has opened the tab manually.

Comment 17

[Karl Seamon]

Sorry to comment 2.5 years later...

Wouldn't the best solution be to only set window.opener when the user middle clicks a link that has a target of '_blank'? In that case, no new security risk is created, and the web site's behavior is consistent regardless of how the user chooses to use the link.

Comment 19

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 20

[Anne (:annevk)]

As Jesse said, we don't want more openers than strictly needed.