Closed
Bug 203158
Opened 21 years ago
Closed 3 years ago
windows opened into tabs by middleclick or ctrl+click have no opener
Categories
(Core :: DOM: Core & HTML, defect, P5)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: nthomass, Unassigned)
References
Details
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•21 years ago
|
||
> - 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 3•21 years ago
|
||
[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 !?)
Comment 4•21 years ago
|
||
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•21 years ago
|
||
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•21 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
Updated•21 years ago
|
Comment 7•21 years ago
|
||
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
Updated•20 years ago
|
Assignee: jag → general
Component: XP Apps → DOM
QA Contact: pawyskoczka → ian
This is a partial dupe of bug 263844. CC'ing danm for his views.
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•20 years ago
|
||
too late to go digging into this for 1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 12•20 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•20 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•20 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•20 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•20 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•17 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•15 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Comment 19•6 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Comment 20•3 years ago
|
||
As Jesse said, we don't want more openers than strictly needed.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•