A link with an URL and additional javascript open shows a popup and an unwanted new window [link with TARGET and onClick=window.open]

VERIFIED FIXED in mozilla1.8beta1



Document Navigation
13 years ago
10 years ago


(Reporter: Stefan Fischer, Assigned: bz)


(4 keywords)

fixed-aviary1.0.1, fixed1.7.6, regression, testcase
Dependency tree / graph
Bug Flags:
blocking1.7.6 +
blocking-aviary1.0.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: need branch landing, URL)


(3 attachments)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050123
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050123

A link to open a single popup window via javasctipt opens the actual popup and
an additional NEW window, both displaying the page. The behaviour up to Mozilla
1.84a, Firefox 1.0 and IE is to open only the popup window.

Reproducible: Always

Steps to Reproduce:
1. add link opening a page by href="MyPage.html" and javascript onClick=
2. specify target="MyWin" and use the same name in
onClick="window.open('MyPage.html', 'MyWin')" 

The following should open popup.html via javascript and then load popup.html
from href="popup.html" into the same window.
<a href="popup.html" onClick="window.open(popup.html, 'ZoomWin')"
target="ZoomWin">Show Popup</a>

example image-links:
Actual Results:  
One (resized) window is opened by javascript and an additonal NEW one by href=,
both displaying the same content.

Expected Results:  
A window with a certain name should have been opened by javascript and the href=
and target= should have loaded the page (again) into the same window.

Comment 1

13 years ago
I can confirm the behavior with Mozilla 1.8b build 2005011805 on WinNT4 and as
stated by the reporter I don't see it with Firefox 1.0.

Steps to reproduce:
1. open the given URL
2. click on the image left to the second project called " 	

I see the following warning in the JS console:

Warning: variable Seite hides argument
Source File:
Line: 39, Column: 6
Source Code:
  var Seite = "../scripts/zoomimage.php?img=" + Seite;
Keywords: regression
Summary: Mozilla 1.86a: a link with an URL and additional javascript open shows a popup and an unwanted new window → Mozilla 1.8a6/1.8b: a link with an URL and additional javascript open shows a popup and an unwanted new window
Version: unspecified → Trunk

Comment 2

13 years ago
Looks like to be the same problem like in Bug 278916, see bug 278916 comment 4.
Summary: Mozilla 1.8a6/1.8b: a link with an URL and additional javascript open shows a popup and an unwanted new window → A link with an URL and additional javascript open shows a popup and an unwanted new window [link with TARGET and onClick=window.open]
Well, I can reproduce this bug, but NOT bug 278916 on Linux.  So they're likely
different problems.

For this bug, it looks like the frameset may be relevant -- if I just load that
subframe as a toplevel page the bug doesn't appear.


13 years ago
OS: Windows XP → All
Created attachment 172585 [details] [diff] [review]

This basically backs out the "fix" for bug 135811.  Now I can't figure out how
finding targets outside our window for subframes _ever_ worked after the fix
for that bug.... jst, any idea?

In any case, what happens is that the subframe asks its parent to look, the
parent doesn't find the target amongst its kids, but has the same tree owner as
aRequestor (the kid), so doesn't ask the treeowner either.  So the named target
is never found.  Before the patch for bug 103638, we had basically the same
code here, which is why I don't understand how it worked... :(	I'd really like
to, if someone can explain it to me.

In any case, this patch also adds code to our treeowners to ensure the
invariant that the treeowner is the requestor only for calls to the root
docshell of type. This should make sure bug 135811 does not reappear.

I didn't change nsDocShellTreeOwner.cpp because I'm still trying to figure out
how that one works, exactly.  It'll probably be the subject of bug 278916.
Assignee: general → bzbarsky
Attachment #172585 - Flags: superreview?(jst)
Attachment #172585 - Flags: review?(danm.moz)
Comment on attachment 172585 [details] [diff] [review]

Ugh, I can't explain how this worked... not w/o digging through old code I
don't have handy.

sr=jst nonetheless.
Attachment #172585 - Flags: superreview?(jst) → superreview+
I _did_ dig through the code before our patch landed... and I still don't see
how it worked.  :(


13 years ago
Component: General → Embedding: Docshell
Keywords: testcase
Product: Mozilla Application Suite → Core
QA Contact: general → adamlock


13 years ago
Attachment #172585 - Flags: review?(danm.moz) → review+
Checked in for 1.8b.
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta

Comment 10

13 years ago
For reference: Disable Targets For Downloads eliminates a common error incurred
by many webmasters, which ultimately causes blank windows to be opened when you
try to download a binary file.   http://www.cusser.net/extensions/


13 years ago
Flags: blocking-aviary1.0.1+
Comment on attachment 172585 [details] [diff] [review]

a=caillon (on behalf of drivers) for checkin to 1.0.1 and 1.7.6
Attachment #172585 - Flags: approval1.7.6+
Attachment #172585 - Flags: approval-aviary1.0.1+
Whiteboard: need branch landing


13 years ago
Flags: blocking1.7.6?
Flags: blocking1.7.6? → blocking1.7.6+
Keywords: fixed-aviary1.0.1
Fixed on 1.0.1 and 1.7 branches.
Keywords: fixed1.7.6

Comment 13

13 years ago
Verified Fixed everywhere with the recent builds (FF101, FFTrunk, M176, Trunk).
Flags: in-testsuite+
Test for this got added in bug 408052.
You need to log in before you can comment on or make changes to this bug.