Closed Bug 277971 Opened 16 years ago Closed 15 years ago

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

Categories

(Core :: DOM: Navigation, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

(Depends on 1 open bug)

Details

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

Attachments

(2 files, 1 obsolete file)

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.
Depends on: 277972
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.
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]
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.
> 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]
Patch

sr=jst
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.
Status: NEW → RESOLVED
Closed: 15 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.