All users were logged out of Bugzilla on October 13th, 2018
> - 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
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: jrgm → paw
Hardware: PC → All
Testcase needs to be updated anyhow --> blocking 142649
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 ?
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?
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
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.
too late to go digging into this for 1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0-
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.
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.
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.
> 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.
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.
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.