Closed
Bug 362303
Opened 19 years ago
Closed 1 year ago
window.opener property erased after posting from a popup
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: sssnake, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8) Gecko/20051111 Firefox/1.5
Pre-history: I post a form from an invisible frame of a complicated frameset. The server reply when everything's ok is something like "<script type='text/javascript'>window.parent.OnComplete()</script>", where the OnComplete() method fills all the necessary fields according to the server-reported results of the operation. It works fine, but sometimes it is necessary to ask the user what choice should be made between several alternatives, then the user's reply is processed by the server, which then sends the final results. I use a popup window opened by js (which initializes the popup's opener property), and the final reply is like "<script type='text/javascript'>window.opener.parent.OnComplete()</script>". This works still fine in IE but sucks in FF.
Having examined the issue I found out that:
1. prior to submitting the form, the window.opener, and all its properties and methods are totally accessible from the popup;
2. after the popup's document is reloaded from POST, alert(window.opener) says "[object Window]";
3. even alert(window.opener.parent) still says "[object Window]";
4. but trying to access window.opener.name results in the following error: "window.opener has no properties" (wow, and how about window.opener.parent?!);
5. calling each of the following - window.opener.parent.OnComplete(), window.opener.parent.alert('Boo!'), window.opener.alert('Boo!'), alert(window.opener.parent.OnComplete.toString()) - results in an uncaught exception (NOT the "window.opener.parent.OnComplete is not a function" error message, usual when the object is simply overwritten by something else - this IS a function, but somehow it is lost).
It is obvious that a _window_ property should not be touched when a _document_ inside the window is reloaded, and it is even more obvious that it should not be erased in such an unclean manner anyway.
Reproducible: Always
Steps to Reproduce:
Well, it's a bit tricky. You have to write a server script responding with a js that opens a popup and writes there a form. Having submitted the form (to the same server script with different parameters or to another one), you should get a javascript that tries to manipulate with the window.opener.
Actual Results:
js error
Expected Results:
all the js running properly
Updated•19 years ago
|
Assignee: nobody → general
Component: General → DOM: Level 0
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
| Reporter | ||
Comment 1•19 years ago
|
||
IMPORTANT ADDITIONS:
First of all, I have to say that this bug appears not only when posting from a popup. In search for a workaround, I changed from a popup to an hidden-and-shown IFRAME. After submitting the form, trying to access the IFRAME's ancestors properties and methods (for example, window.parent.name or top.document.getElementById()) also resulted in an uncaught exception.
Then I constructed a test frameset + a test server script, with the same js running in the respective frames. Surprisingly, it worked fine. Trying to minimize as much as possible the difference between the test frameset and the real one, I finally found the cause. When the form action is a relative URL, everything works fine. When it is an absolute one, with 'http://servername' in the beginning - there is a bug.
Updated•16 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Comment 2•7 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046
Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.
If you have questions, please contact :mdaly.
Priority: -- → P5
Updated•3 years ago
|
Severity: normal → S3
Updated•1 year ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•