Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 98140 invoked from network); 31 Mar 2004 18:05:30 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 31 Mar 2004 18:05:30 -0000 Received: (qmail 48863 invoked by uid 500); 31 Mar 2004 18:05:18 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 48801 invoked by uid 500); 31 Mar 2004 18:05:17 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 48780 invoked from network); 31 Mar 2004 18:05:17 -0000 Received: from unknown (HELO exchange.sun.com) (192.18.33.10) by daedalus.apache.org with SMTP; 31 Mar 2004 18:05:17 -0000 Received: (qmail 29847 invoked by uid 50); 31 Mar 2004 18:06:00 -0000 Date: 31 Mar 2004 18:06:00 -0000 Message-ID: <20040331180600.29846.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: dev@cocoon.apache.org Cc: Subject: DO NOT REPLY [Bug 28102] New: - [PATCH] Client-side: window.onload handler clobbered by X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28102 [PATCH] Client-side: window.onload handler clobbered by Summary: [PATCH] Client-side: window.onload handler clobbered by Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: CocoonForms AssignedTo: dev@cocoon.apache.org ReportedBy: ml@wrinkledog.com See: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107952785825215&w=2 Granted, the transformation on the element does preserve whatever JS statements may have been contained in the transformed , but those in themselves are not the window.onload handler. Rather, the effect of @onload is to set (i.e., overwrite) window.onload. So if I want my onload logic not to be clobbered here, I have to specify it via @onload — but this is not convenient for me, as my HTML element is generated by a common page stylesheet several transformations down the pipeline from the source document that cares about the onload handler. I shouldn't have to add more coupling (tags and XSL) to drive this styling template and micromanage the element it writes; much nicer to say "window.onload = initialize;" or whatever, in an external javascript resource (I already have transformations in place that let me drive a child of into the HTML... e.g.,