277971 - [FIX]Random tabs can target a load to the currently-open tab

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD:  Any current build (including one with the patch to bug 103638 in it).

STEPS TO REPRODUCE:
1)  Load attached testcase in a background tab
2)  Make sure current tab is not a bugzilla.mozilla.org tab.
3)  Wait 5 seconds

ACTUAL RESULTS: The current tab gets replaced by google.com

EXPECTED RESULTS: Either treat the load as a popup, or block the load for
security reasons, or something.

I'm not sure why we're even ending up able to access the treeitem with the patch
for bug 103638.  But past that, there's global window code that (incorrectly,
imo) special-cases the _main target.  See nsGlobalWindow::CheckOpenAllow.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note, though, that this code may not be hitting CheckOpenAllow, since it doesn't
use window.open.... so the issue is likely a pure-docshell one with that testcase.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This probably also depends on bug 273984

Comment 3

[Dan M]

The patch for bug 103638 didn't address finding named windows in tabs. That's
bug 121377, anyway. So what's the testcase? I'm curious because I wanted to try
it against my local build, which has no problem with bug 273984. (Though that'll
change as soon as I pull the 103638 patch.)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Sorry, got disconnected before I could attach this...

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that doesn't run into silly tab-switching dialogs

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

The idea is that targetable shells should not "leak" _main or _content outside of themselves.  nsDocShellTreeOwner already works, and for the chrome tree owner always getting the primary content shell is correct (since chrome shells are never content-targetable).  Fixes this bug and bug 273984.

Comment 7

[[e-mail]]

Comment on attachment 214983 [details] [diff] [review]
Patch

Don't mind me but I fail to see how to equal nsIDocShellTreeItem pointers can fail to have the same COM identity or vice versa.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> or vice versa.

Tearoffs.  And yes, I know that we currently have random front-end code (that includes xpfe/appshell!) making ASSumptions that this interface is never going to be a tearoff.  I don't like it making those assumptions.

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 214983 [details] [diff] [review]
Patch

sr=jst

Comment 10

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk and 1.8 branch.