Open Bug 249751 Opened 20 years ago Updated 2 years ago

Links whose onclick closes the window fail to trigger link

Categories

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

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

People

(Reporter: brainnolo, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

(Whiteboard: docshell rewrite) 

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.
Could be related to the fix for bug 246448 ?
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>
It uses a normal same-origin check, which requires the pages to be on the same
hostname and same port.
it  must be bugged, because the pages ARE on the same host, same port.
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


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.
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.  
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.
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.
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.
Addition to comment #10.
 - browser.frame.validate_origin is not displayed by about:config.
(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?

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.
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). 
(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


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.
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
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.
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All
Summary: hyperlink targetting an <iframe> in another window is ignored (click doesn't do anything) → Links whose onclick closes the window fail to trigger link
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.
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.
Whiteboard: docshell rewrite
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 :)
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...
Bug 84833 is different case (form submission instead of link) but same solution
can be applicable.
So set dependency of this bug on it.
Depends on: 84833
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.