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

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Stefan Fischer]

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:
http://www.uni-bayreuth.de/departments/kunsterziehung/didaktik/de/index.php?go=projekte.php
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

[OstGote!]

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 " 	
Flügeleien".


I see the following warning in the JS console:

Warning: variable Seite hides argument
Source File:
http://www.uni-bayreuth.de/departments/kunsterziehung/didaktik/scripts/global.js
Line: 39, Column: 6
Source Code:
  var Seite = "../scripts/zoomimage.php?img=" + Seite;

Comment 2

[OstGote!]

Looks like to be the same problem like in Bug 278916, see bug 278916 comment 4.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Frame for testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

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.

Comment 7

[Johnny Stenback (:jst)]

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

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

sr=jst nonetheless.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I _did_ dig through the code before our patch landed... and I still don't see
how it worked.  :(

Comment 9

[Boris Zbarsky [:bzbarsky]]

Checked in for 1.8b.

Comment 10

[Worcester12345]

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/

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

a=caillon (on behalf of drivers) for checkin to 1.0.1 and 1.7.6

Comment 12

[Johnny Stenback (:jst)]

Fixed on 1.0.1 and 1.7 branches.

Comment 13

[Jay Patel [:jay]]

Verified Fixed everywhere with the recent builds (FF101, FFTrunk, M176, Trunk).

Comment 14

[Boris Zbarsky [:bzbarsky]]

Test for this got added in bug 408052.