Closed
Bug 277971
Opened 20 years ago
Closed 19 years ago
[FIX]Random tabs can target a load to the currently-open tab
Categories
(Core :: DOM: Navigation, defect)
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)
271 bytes,
text/html
|
Details | |
5.24 KB,
patch
|
benjamin
:
review+
jst
:
superreview+
jst
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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.
![]() |
Assignee | |
Comment 1•20 years ago
|
||
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.
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.)
![]() |
Assignee | |
Comment 4•20 years ago
|
||
Sorry, got disconnected before I could attach this...
![]() |
Assignee | |
Updated•19 years ago
|
Whiteboard: [window targeting]
![]() |
Assignee | |
Comment 5•19 years ago
|
||
Attachment #170968 -
Attachment is obsolete: true
![]() |
Assignee | |
Updated•19 years ago
|
![]() |
Assignee | |
Comment 6•19 years ago
|
||
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)
![]() |
Assignee | |
Updated•19 years ago
|
Attachment #214983 -
Flags: approval-branch-1.8.1?(jst)
Comment 7•19 years ago
|
||
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.
![]() |
Assignee | |
Comment 8•19 years ago
|
||
> 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.
![]() |
Assignee | |
Updated•19 years ago
|
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
Updated•19 years ago
|
Attachment #214983 -
Flags: review?(benjamin) → review+
Comment 9•19 years ago
|
||
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+
![]() |
Assignee | |
Comment 10•19 years ago
|
||
Fixed on trunk and 1.8 branch.
![]() |
Assignee | |
Updated•18 years ago
|
Target Milestone: mozilla1.8.1alpha1 → mozilla1.9alpha
You need to log in
before you can comment on or make changes to this bug.
Description
•