Closed Bug 277971 Opened 19 years ago Closed 18 years ago

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


(Core :: DOM: Navigation, defect)

Not set





(Reporter: bzbarsky, Assigned: bzbarsky)


(Depends on 1 open bug)


(Keywords: fixed1.8.1, Whiteboard: [window targeting])


(2 files, 1 obsolete file)

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

1)  Load attached testcase in a background tab
2)  Make sure current tab is not a tab.
3)  Wait 5 seconds

ACTUAL RESULTS: The current tab gets replaced by

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.
Depends on: 277972
Note, though, that this code may not be hitting CheckOpenAllow, since it doesn't
use so the issue is likely a pure-docshell one with that testcase.
This probably also depends on bug 273984
Depends on: 273984
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.)
Attached file Testcase (obsolete) —
Sorry, got disconnected before I could attach this...
OS: Linux → All
Whiteboard: [window targeting]
Depends on: 326009
Blocks: 273984
No longer depends on: 273984
Attached patch PatchSplinter Review
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.
Attachment #214983 - Flags: superreview?(jst)
Attachment #214983 - Flags: review?(benjamin)
Attachment #214983 - Flags: approval-branch-1.8.1?(jst)
Comment on attachment 214983 [details] [diff] [review]

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.
> 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.
Summary: Random tabs can target a load to the currently-open tab → [FIX]Random tabs can target a load to the currently-open tab
Target Milestone: --- → mozilla1.8.1alpha1
Attachment #214983 - Flags: review?(benjamin) → review+
Comment on attachment 214983 [details] [diff] [review]

Attachment #214983 - Flags: superreview?(jst)
Attachment #214983 - Flags: superreview+
Attachment #214983 - Flags: approval-branch-1.8.1?(jst)
Attachment #214983 - Flags: approval-branch-1.8.1+
Fixed on trunk and 1.8 branch.
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Target Milestone: mozilla1.8.1alpha1 → mozilla1.9alpha
You need to log in before you can comment on or make changes to this bug.