Closed Bug 65069 Opened 24 years ago Closed 24 years ago

Bug or feature? JavaScript function pointer is still alive after page reload

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
minor

Tracking

()

VERIFIED INVALID
Future

People

(Reporter: udo.offermann, Assigned: jst)

Details

Attachments

(4 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.7) Gecko/20010109 BuildID: Gecko/20010109 It seems that JavaScript function objects are still valid when the page in which the function objects are defined is reloaded. As far as I understand what's going on when a page is reloaded, the objects (DOM, JS, ...) of the old document are deleted and the new DOM and JS objects are created. So references to old objects inside other frames become invalid. But it is still possible to use these old references (perhaps only until the memory is reused?). I wonder if this is a bug or a feature. B.T.W: IE produces in this circumstance the following exception: "Can't execute code from a freed script" Reproducible: Always Steps to Reproduce: 1 given a page with an iframe 2 the document inside the iframe contains a function called foo 3 the entire page contains a reference to function foo called bar 4 refresh the iframe 5 use the function pointer bar Actual Results: it works! The JS statement bar(); results in executing function foo! Expected Results: a JS exeption like "Can't execute code from a freed script" If you want I can provide two demo html-files which showes the effect. Please let me know where to send to.
Browser, not engine. Reassigning to DOM Level 0 - udoo, yes, if you have reduced testcases, please attach them to this bug. See the "Create a new attachment" link above. That would be a great help -
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: Javascript Engine → DOM Level 0
Ever confirmed: true
QA Contact: pschwartau → desale
Summary: Bug or feature? JavaScript function pointer is still alive after page reload → Bug or feature? JavaScript function pointer is still alive after page reload
Udo has sent a reduced testcase, in the form of two HTML files I will attach: " startme.html and iframe.html. Simply copy them into the same webfolder and navigate to startme.html. Inside the iframe you can press "set function pointer" which stores a pointer to function foo defined inside the iframe. Before *and after* you reload the iframe you can press "use Function Pointer" and function foo shows an alert box - so the function object is still alive *after* frame reload! If you try to store the foo function pointer again, you will see that the new pointer to function foo references to another object than the old one. " - Thanks, Udo!
Attached file File #2 of the testcase - iframe.html (deleted) —
Here is Udo's HTML for file #1 of the testcase - startme.html - <HTML> <HEAD> <META http-equiv="content-type" content="text/html; charset=iso-8859-1"> <TITLE>Invalid JS objects are still alive</TITLE> <LINK rel="StyleSheet" type="text/css" href="../styles/style.css"> <SCRIPT> function setFunctionPointer( fptr ) { if (window.fptr != null) { var lsNot = (window.fptr != fptr)? "*not* ": ""; if (confirm( "function pointer already stored. Pointers are " + lsNot + "equal.\nReplace with new pointer?") ) { window.fptr = fptr; alert( "Function pointer stored" ); } } else { window.fptr = fptr; alert( "Function pointer stored" ); } } function useFPtr() { if (window.fptr != null) { window.fptr(); } else { alert( "please set function pointer first" ); } } </SCRIPT> </HEAD> <BODY> <H2>Invalid JS objects are still alive</H2> <P> 1. Press "set function pointer" inside iframe<BR> 2. Press "refresh iframe" inside iframe<BR> 3. Press "use Function Pointer" - it works!<BR> 4. Press "set function pointer" again - pointers are unequal!<BR> <BUTTON onclick="useFPtr()">use Function Pointer</BUTTON> <P> <IFRAME src="iframe.html"></IFRAME> </BODY> </HTML>
And here is Udo's HTML for file #2 of the testcase - iframe.html - <HTML> <HEAD> <META http-equiv="content-type" content="text/html; charset=iso-8859-1"> <SCRIPT> function foo() { alert( "Greetings from Iframe" ); } </SCRIPT> </HEAD> <BODY> <H3>I am an IFrame</H3> <P> <BUTTON onclick="parent.setFunctionPointer( foo )">set function pointer</BUTTON> <BUTTON onclick="location.replace( 'iframe.html' )">refresh iframe</BUTTON> </P> </BODY> </HTML>
Brendan, could you explain why this works (or shouldn't work)? AFAIK there's no problem here so this is a feature and not a bug, but I can't explain why this does *not" work in IE. Setting target milestone to Future to keep this off my bug radar.
Severity: major → minor
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → Future
IE is broken, and always has been. I don't understand why anyone would want weak refs here, instead of the strong ones that JS sensibly provides. Functions are just objects, and whether I have one window or frame, or many, and no matter how many times the garbage collector runs, if I do: var o = {p:'hi'}; var o2 = o; o = null so long as o2 refers to the object with property 'p' of value 'hi', that object won't become garbage. /be
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Brendan, your object won't become garbage as long as the page is not reloaded. Look at the following html doc: <HTML> <HEAD> <TITLE></TITLE> <SCRIPT> var o = null; function setValue() { o = new Date(); } function lookupValue() { alert( o ); } </SCRIPT> </HEAD> <BODY> <BUTTON onclick="setValue()">set value</BUTTON> <BUTTON onclick="lookupValue()" >lookup value</BUTTON> </BODY> </HTML> you can set the object and do a lookup, but if you reload the page, o will have the value null. I wonder why function pointers *seems* to be valid after page reload. Udo
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Udo, as brendan pointed out JS references are strong references so refreshing the iframe in your first testcase does indeed clear out everything in the iframe window so that the objects in that window is no longer accessable through that window but since you have a strong reference in the outer document to a function object in the iframe window the function object remains valid even if the iframe is reloaded (due to the live strong reference to the function). Reloading a window (or [i]frame) does indeed clear out all references to all properties on the window that is reloaded so that the objects that were defined on the window prior to reloading are no longer defined on the window, but if there are strong references to those properties in other windows those references remain untouched. As brendan said, IE is broken, Mozilla works as expected.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → INVALID
Marking Verified -
Status: RESOLVED → VERIFIED
Attached file updated version of 'iframe.html' (deleted) —
I added two buttons to "iframe.html" called "clear iframe" and "delete foo" to verify your explanation about strong references in JS. If you 1) press "set function pointer" 2) press "clear iframe" 3) press "use function pointer" you get the error "foo is not defined". Does this match to the strong refernce principle? I discovered another behaviour which is hard for me to understand: 1) press "set function pointer" 2) press "delete foo" 3) press "use function pointer" -> results in an expected error 4) press "refresh iframe" 5) press "use function pointer" -> *it works!* 6) press "set function pointer" -> the references are *unequal* Sorry of being so intractable. Udo
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
> If you > 1) press "set function pointer" > 2) press "clear iframe" > 3) press "use function pointer" > > you get the error "foo is not defined". Does this match to the strong refernce > principle? Yes, it does. You define function foo in your iframe as: function foo() { alert( foo.toString() ); } Then when you click "set fptr" you'll have a strong reference to the function defined as foo in the iframe. When iframe is cleared the function foo is removed fomr the iframe window, and when the function is used it tries to execute the function, which does "alert(foo.toString());" on the old iframe context but since that context (window) was cleared and you get the error "foo is not defined" when the function calls foo.toString();. Exactly as expected. > I discovered another behaviour which is hard for me to understand: > 1) press "set function pointer" This will set window.fptr in startme.html to the function foo() in the iframe window. > 2) press "delete foo" The function foo is deleted from the iframe window. > 3) press "use function pointer" -> results in an expected error The function runs and tries to execute "foo.toString();" but foo doesn't exist any more in the iframe. > 4) press "refresh iframe" The iframe is loaded again, the function foo exists once again. > 5) press "use function pointer" -> *it works!* Yes, it works since foo does exist now. > 6) press "set function pointer" -> the references are *unequal* Yes, since window.fptr is the function foo in the iframe before it was reloaded and you're now setting it to the function in the reloaded iframe. Same "function", but different function objects. No problems here that I can see. INVALID.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → INVALID
Udo: change alert(foo.toString()) to alert(arguments.callee) to get the same effect in a way that doesn't depend on the function's name still being defined in its scope chain. Note that a (property) name such as foo in the inner iframe is just one of possibly many strong refs, but for a function, it will be the only name on the function's scope chain. JS uses static scoping, so the scope chain of an activation of foo depends only on the object in which foo was declared (the inner iframe). Once that name is gone from the scope chain, the alert is doomed, but the function formerly known as foo still exists (and even remembers its declared name, as the decompilation produced by alert(arguments.callee) shows). Don't confuse not finding a particular (named) strong ref to an object with the object being dead. /be
Marking Verified -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: