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.
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.
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
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
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.