Open
Bug 249751
Opened 21 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)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
NEW
People
(Reporter: brainnolo, Unassigned)
References
(Depends on 1 open bug, )
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.
Reporter | ||
Comment 2•21 years ago
|
||
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•21 years ago
|
||
It uses a normal same-origin check, which requires the pages to be on the same hostname and same port.
Reporter | ||
Comment 4•21 years ago
|
||
it must be bugged, because the pages ARE on the same host, same port.
Comment 5•21 years ago
|
||
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
Reporter | ||
Comment 6•21 years ago
|
||
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•21 years ago
|
||
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.
Reporter | ||
Comment 8•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
Addition to comment #10. - browser.frame.validate_origin is not displayed by about:config.
Comment 12•21 years ago
|
||
(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•21 years ago
|
||
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.
Reporter | ||
Comment 14•21 years ago
|
||
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).
Reporter | ||
Comment 15•21 years ago
|
||
(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
Reporter | ||
Comment 16•21 years ago
|
||
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•21 years ago
|
||
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
Reporter | ||
Comment 18•21 years ago
|
||
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•21 years ago
|
||
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
Updated•21 years ago
|
Reporter | ||
Comment 20•21 years ago
|
||
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•21 years ago
|
||
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
Reporter | ||
Comment 22•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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
Updated•6 years ago
|
Product: Core → Core Graveyard
Assignee | ||
Updated•6 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•