Weird Opera bug?

[MartinRinehart]

I'm working on a website that nests framesets within other framesets.
I want a click in one top-level frame to show/hide a menu in a second
level frame. Hete's a code fragment:

var cousin2_doc = brother_frameset['main-main'].document
var d = cousin2_doc

d.wp = function( obj ) { this.write( obj + '<p>' ) }
alert( d + ', ' + d.wp )

d.wp( 23 )
alert( d + ', ' + d.wp )

At the first alert(), we're happy. The second alert shows that the
function is gone. I'm using KDE on Linux. Konqueror doesn't have any
problem with this. Any ideas for a workaround?

The just-started project is at http://www.MartinRinehart.com/08 - the
offending piece is in main/lower-left.html.

 

[Thomas 'PointedEars' Lahn]

I'm working on a website that nests framesets within other framesets.

Framesets are already a bad idea as they are often not needed. Nesting them
makes it only worse.

I want a click in one top-level frame to show/hide a menu in a second
level frame. Hete's a code fragment:

var cousin2_doc = brother_frameset['main-main'].document
var d = cousin2_doc

d.wp = function( obj ) { this.write( obj + '<p>' ) }
alert( d + ', ' + d.wp )

d.wp( 23 )
alert( d + ', ' + d.wp )

At the first alert(), we're happy. The second alert shows that the
function is gone. I'm using KDE on Linux. Konqueror doesn't have any
problem with this.

The created Function object is _not_ gone (at least not garbage-collected at
once), but the test shows that you could not augment the Document host
object with a property, which is not surprising. Host objects do not need
to support (arbitrary) augmentation, and it is up to their implementors to
define to what extent augmentation is possible.

Any ideas for a workaround?

More for a *fix*, remove `.document', and use `document' instead of `this'
in the method. If anything, functions of a global execution context are
methods of the Global/Window Object of this context, not its Document
object. That said, you should not expect it to be possible to define global
methods this way as Window objects are host objects, too.

You should end all these lines with a semicolon so as not to rely
on automatic semicolon insertion and the side-effects this can have.


PointedEars

 

[MartinRinehart]

Framesets are already a bad idea as they are often not needed. Nesting them

makes it only worse.

I love my nested framesets. They help make pages dynamic. Try

http://www.ClintonBushCharts.com

In "Our Charts" you're looking at nested framesets. If you start with
GDP you
see the regular effect. Then on to Receipts or Expenses and you see
the nested
menu split into a top and bottom portion. Really gets the job done
well.

The created Function object is _not_ gone (at least not garbage-collected at
once), but the test shows that you could not augment the Document host
object with a property, which is not surprising. Host objects do not need
to support (arbitrary) augmentation, and it is up to their implementors to
define to what extent augmentation is possible.

Hmmm. Don't know about garbage collection, but if my last reference is
gone
to me it's gone. The problem is that at the first alert the object is
shown as
augmented, the call that prints 23 works, and then, after one use,
the
attribute disappears.

You should end all these lines with a semicolon so as not to rely
on automatic semicolon insertion and the side-effects this can have.

In Python, ending every line with a semi is a possibility, but no one
ever
does. You'd be laughed at. I googled this and it's universally
prescribed
as best practice in Javascript, but none of the reasons were
persuasive.
What is this "automatic semi insertion and the side effects"?

 

[Henry]

(e-mail address removed) wrote:



The created Function object is _not_ gone (at least not
garbage-collected at once), but the test shows that you could
not augment the Document host object with a property, which
is not surprising. Host objects do not need to support
(arbitrary) augmentation, and it is up to their implementors
to define to what extent augmentation is possible.

<snip>

Wouldn't the symptoms of a failure to augment a host object be an
'undefined' appearing in the first alert, followed by an exception
being thrown at the - d.wp( 23 ) - line?

The symptoms described are the first alert showing evidence of a
function, the call to that function (as a method of a document)
executing successfully and the final alert indicating the (now)
missing document method. I would suspect that the culprit is the line
- this.write( obj + '<p>' ) - inside the method, as that is
effectively a - document.write - call and that will (if the pertinent
document has finished loading) clear the existing document and replace
its contents. The browser differences may be accounted for by
different handling of this process by the browser where some create a
new document (so the existing - d - reference still refers to the old
document object (which then still shows the assigned method)) and
others (apparently like Opera) 're-set' the existing document
(removing any augmented properties in the process).

 

[MartinRinehart]

Problem solved:

var cousin2_doc = brother_frameset['main-bottom'].document
var d = {}
d.doc = cousin2_doc

d.wp = function( obj ) { this.doc.write( obj + '<p>' ) }
d.wp( d.wp )

var cn = cousin1_doc.childNodes
d.wp( cn )

 

[Thomas 'PointedEars' Lahn]

Problem solved:

var cousin2_doc = brother_frameset['main-bottom'].document
var d = {}
d.doc = cousin2_doc

d.wp = function( obj ) { this.doc.write( obj + '<p>' ) }
d.wp( d.wp )

var cn = cousin1_doc.childNodes
d.wp( cn )

cousin2_doc.write(cn);

somehow strikes me as being a lot less bloated.


PointedEars

 

[Thomas 'PointedEars' Lahn]

<snip>

Wouldn't the symptoms of a failure to augment a host object be an
'undefined' appearing in the first alert, followed by an exception
being thrown at the - d.wp( 23 ) - line?

Not necessarily. I think I have seen this sort of "late garbage collection"
of user-defined properties of host objects before, but I don't remember
where and when anymore.

[...] I would suspect that the culprit is the line
- this.write( obj + '<p>' ) - inside the method, as that is
effectively a - document.write - call and that will (if the pertinent
document has finished loading) clear the existing document and replace
its contents. [...]

You are right, this is more probable and would explain why the OP's
(somewhat bloated) workaround works.


PointedEars

 

[MartinRinehart]

Thanks gentlemen.

I've got it to where it works, which is good.

But I'm totally confused, which is not so good.

Given two frames, let's say A and B, js in A gets reference to B's
document and uses it to doc.write( something ). That would, I thought
erase prior content of B. How would that effect objects in js in A's
document? And now that I've thought about it, I see no reason why my
workaround should work. Any ideas?

 

[Thomas 'PointedEars' Lahn]

Given two frames, let's say A and B, js in A gets reference to B's
document and uses it to doc.write( something ). That would, I thought
erase prior content of B. How would that effect objects in js in A's
document?

When you add methods to an object existing in another frame B and overwrite
the contents of frame B afterwards, the least you can expect is that these
methods cease to exist.

And now that I've thought about it, I see no reason why my workaround
should work. Any ideas?

Your workaround adds a method to an object existing in frame A instead.


PointedEars

 

[MartinRinehart]

Your workaround adds a method to an object existing in frame A instead.

PointedEars

How obvious! Thanks.