All users were logged out of Bugzilla on October 13th, 2018

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

NEW
Unassigned

Status

()

P5
normal
16 years ago
4 months ago

People

(Reporter: nthomass, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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]
> - 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....
Assignee: hewitt → jaggernaut
Status: UNCONFIRMED → NEW
Component: JavaScript Console → XP Apps
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: jrgm → paw
Hardware: PC → All

Comment 2

16 years ago
Testcase needs to be updated anyhow --> blocking 142649
Blocks: 142649
[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".
Summary: Read window.opener javascript test failed when open in a tab → In <win011.html> JavaScript Testcase: 'window.opener' should return '[object Window]' instead of 'null' (related to when opened in a tab !?)
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.
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 ?
Depends on: 138402

Comment 6

15 years ago
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?
Summary: In <win011.html> JavaScript Testcase: 'window.opener' should return '[object Window]' instead of 'null' (related to when opened in a tab !?) → ctrl+click on a link does not set window.opener
Blocks: 138402
No longer depends on: 138402
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 ??
No longer blocks: 142649
Assignee: jag → general
Component: XP Apps → DOM
QA Contact: pawyskoczka → ian

Updated

14 years ago
Flags: blocking-aviary1.0?
This is a partial dupe of bug 263844. CC'ing danm for his views.

Comment 9

14 years ago
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.
Summary: ctrl+click on a link does not set window.opener → windows opened into tabs by middleclick or ctrl+click have no opener
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

14 years ago
too late to go digging into this for 1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 12

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
> 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

14 years ago
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

11 years ago
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.

Updated

10 years ago
Duplicate of this bug: 463245
Assignee: general → nobody
QA Contact: ian → general
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.