249751 - Links whose onclick closes the window fail to trigger link

Status: NEW

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Michele Balistreri]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; it-it) AppleWebKit/125.2 (KHTML, like Gecko) Safari/125.8
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040628 Firefox/0.9.1

Sorry if i can't provide the page but is on my comp, however: I have a gallery of photo,in an <iframe> 
(surrounded by a menu and footer outside the iframe), when you click on a photo a pop-up opens, this 
pop-up has an "order" button wishing to open the order page INSIDE the <iframe> in the parent 
window. Clicking on it doesn't make anything happen. Using normal frames, everything is ok. Using IE, 
Safari, Konqueror, it works. The <iframe> is using both "name" and "id" properties so it can be 
referenced in the "target" property of an hypertextual link.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[(not currently active) Ted Mielczarek]

Could be related to the fix for bug 246448 ?

Comment 2

[Michele Balistreri]

probably is related to this, but is too restrictive, it could at least check if the pages are on the same IP, 
however is strange that in a normal frameset it work, the problem is just with <iframe>

Comment 3

[Jesse Ruderman]

It uses a normal same-origin check, which requires the pages to be on the same
hostname and same port.

Comment 4

[Michele Balistreri]

it  must be bugged, because the pages ARE on the same host, same port.

Comment 5

[WADA:World Anti-bad-Duping Agency]

I experienced same problem as Bug 247070 (FRAME case) at a Japanese site on
Firefox 0.9.1, and setting "docshell.frameloadcheck.disabled" to true was a
workaround.
However, the problem did not occur on latest trunk nightly of Firefox.

(Q1)Setting "docshell.frameloadcheck.disabled" to true is a effective workaround?
     See 3rd section of Known Issues in Release Notes of Firefox 0.9.1 
     ( http://www.mozilla.org/products/firefox/releases/0.9.html )
(Q2)How about latest nightly in "/firefox/nightly/latest-trunk/" ?
    Are there any difference among next cases?
     (a) when docshell.frameloadcheck.disabled=true is set by about:config
     (b) when docshell.frameloadcheck.disabled=false is set by about:config
     (c) when docshell.frameloadcheck.disabled is reset by about:config

Comment 6

[Michele Balistreri]

It looks like on MacOSX there isn't docshell.frameloadcheck.disabled option. I've been looking in about:
config both with filters and manually but nothing shows up about docshell.* and there isn't any similar 
entry. I'll try now the lastest build. However my site is now live so you can check too, if you want.

http://www.vbcoltelli.com/, then click on Galleria Coltelli, click on a Knife that is available for sale 
(KIF_1261.jpg) and from the window that will open, click on the Ordina button it should close the little 
window *and* open the order page on the main window.

Comment 7

[WADA:World Anti-bad-Duping Agency]

docshell.frameloadcheck.disabled is not displayed if not defined.
You need to define this keyword(Boolean) through context menu in about:config,
then set it's value to true" or false.
To reset it(set it back to internal default), "Reset" form context menu is
required.  

Comment 8

[Michele Balistreri]

Setting this key on any value doesn't produce any effect in this case, still it doesn't work. I've tried both 
on 0.9.1 and today's (20040707) nightly build. The problem is still there.

Comment 9

[Johnny Stenback (:jst)]

Any chance you could write up a trivial testcase that replicates this problem?
Look at the source of the site where you see the problem, and write similar HTML
files for us developers to put on different servers to see what is going on.

It could be that you're running into a case that we intentionally block, those
cases would be if you're targetting a link at an [i]frame in a different window
and the link and the target (and the document(s) contianing the target) are from
different domains. But even in those cases, if your link doesn't load in the
iframe, it should load in a new top-level window.

And is there any JavaScript involved here? I.e. do the links have javascript:
URL's or onclick handlers?

And one more thing to test, with a nightly build (*not* Firefox 0.9 or 0.9.1, or
Mozilla 1.7), try setting the preference "browser.frame.validate_origin" to the
boolean value false, and let us know if that changes anything.

Comment 10

[WADA:World Anti-bad-Duping Agency]

Michele Balistreri's site ( http://www.vbcoltelli.com/ ) has no problem when
Mozilla Suite Trunk Nightly(Mozilla 1.8a2, 2004070707 ZIP build on Win-2K).
docshell.frameloadcheck.disabled was reset status(not displayed in about:config)
in my test.

Comment 11

[WADA:World Anti-bad-Duping Agency]

Addition to comment #10.
 - browser.frame.validate_origin is not displayed by about:config.

Comment 12

[WADA:World Anti-bad-Duping Agency]

(Correction of Comment #10 and Comment #11) 

Problem described in Comment #9 was recreated on Mozilla Suite.
Last step of "open the order page on the main window" was not executed.
(Sorry but I misunderstood that problem was opening a photo in child window.) 

However, this is not a bug, I think.

Secinario is;
(1) HTML of IFRAME(id="content") in a main window 
    <a ... onClick="MyWindow=window.open('viewer.php?....','MyWindow',....)">
    This opens a child window(dependent=no) and loads a HTML(same site).
(2) "Ordina" button in the child window
    <a target="content" id="order" href="ordinazioni.php?code=1307" ...  
       onClick="window.close()">
    "window.close()" of onClick closes myself.
    Therefore, <a target="content" href="ordinazioni.php?code=1307">
    can not be executed any more.
    This is normal and valid behaviour, I think.

    (Older Mozilla probably executed href even after window.close is requested.)
    (But I believe this was not a good behaviour.)
    (This is possibly result of event scheduling algorythm change.)
    (I do not know about non W3C-complient IE's behaviour.)

Michele Balistreri, What will happen when "window.close()" is not requested in
child window?
Did your site work in the past?
What was the browser?
What version if Mozilla family?

Comment 13

[WADA:World Anti-bad-Duping Agency]

If my Comment #12 is right, simple workaround is;
 - Schedule window.close of myself after link operation by <a>.
   eg. self.settimeout("window.close();",1000); in onClick.

Comment 14

[Michele Balistreri]

Looks like Comment #11 is right, disabling Javascript in Firefox, thus not making the windows close, 
makes the link work. I still don't know if this isn't a bug, because all other browsers works fine with it 
(i've had the chance to try Konqueror, Safari 1.2, IE 4, IE 5, IE 5.5, IE 6). 

Comment 15

[Michele Balistreri]

(In reply to comment #14)
> Looks like Comment #11 is right, disabling Javascript in Firefox, thus not making the windows close, 
> makes the link work. I still don't know if this isn't a bug, because all other browsers works fine with it 
> (i've had the chance to try Konqueror, Safari 1.2, IE 4, IE 5, IE 5.5, IE 6). 

Sorry i meant Comment #12, not #11

Comment 16

[Michele Balistreri]

I made another test, i found an old version of my site where i was using a 3 frames <frameset> instead 
of a page with an <iframe>. The Javascript is identical in viewer.php and i check everything else to be 
at the right place. It works just nice with Firefox 0.9.1 and 20040707.

So the scenario is, when targetting to frame in a <frameset>, link from closed windows works. When 
doing it to an <iframe>, it doesn't.

Comment 17

[WADA:World Anti-bad-Duping Agency]

Bug 84833 and DUPs of it report similar situations(your IFRAME case) due to
window.close() to myself in onClick. 
> Bug 84833 : calling self.close() right after calling submit() cancels submission

Comment 18

[Michele Balistreri]

I think, and i may be wrong, that the problem is in the way the "close()" function of javascript is 
interpreted. It destroys the page. I think it should instead just close the window and keep in memory 
the page until the last instruction in queue has been executed. I mean: I click on a link it: it knows it 
must do 2 things: execute the possible javascript, then, go to the linked page. When the queue of 
actions to do is  finished AND the window is closed, then the page has ceased to exist. That's also true 
for submitting forms: first the windows disappear, then  the form is submitted, then the page is 
destroyed.

Comment 19

[Johnny Stenback (:jst)]

Yes, the problem is indeed that we don't follow links after a window has been
closed. The problem is that the code in
nsGenericHTMLElement::HandleDOMEventForAnchors() doesn't work as expected if it
can't get a presshell from the given prescontext, but even with that fixed, the
code in nsGenericElement::TriggerLink() doesn't work since it can't get an
nsILinkHandler from the prescontext after the window has been closed. Updating
summary to reflect the real problem here.

Is this a regression?

Comment 20

[Michele Balistreri]

What about reimplementing the close() javascript function to actually just schedule the real window 
closure after the other actions has been executed?  is there any "actions queue" or something like that? 
i guess it works with events so it should be possible. Or the close() function could just "hide" the 
window and then when all actions are executed, a check to see wheter the window is displayed will 
decide if dispose of it or not. I hope i've been clear, and i didn't say stupid things eheh.

Comment 21

[Johnny Stenback (:jst)]

Yes, we do have an "action queue", known as the event queue. The problem is that
link clicks are also handled off of the event queue, and the link click would be
scheduled after the window close (because of the order in which things happen
during DOM event flow), so we'd still have the same problem, even if the window
didn't close immediately :-(

Fixing this will take some rearchitecturing of our docshell code etc, which is
scheduled, but won't happen any time soon.

Comment 22

[Michele Balistreri]

Well i guess that fixing it another way would result in something not really polished, anyway probably 
the best thing to do is to change the way close()  event AND link handling are done now. I guess a fix is 
possible only if at the time window.close() is called firefox can be somehow aware of the link, and i 
don't think this is the case (right?). We'll all wait with unpatience. Well, at least i will :)

Comment 23

[Johnny Stenback (:jst)]

FYI, you can work around this bug on your site if you want to by not closing the
window right away, close it from JS off of a 100ms timeout or somesuch and you
won't see this problem. Not a sollution, but a way around the problem...

Comment 24

[WADA:World Anti-bad-Duping Agency]

Bug 84833 is different case (form submission instead of link) but same solution
can be applicable.
So set dependency of this bug on it.