cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Feliciano Borrego (JIRA)" <>
Subject [jira] Commented: (COCOON-1112) [PATCH] Client-side: window.onload handler clobbered by <body onload="...">
Date Wed, 14 Jun 2006 16:10:30 GMT
    [ ] 

Feliciano Borrego commented on COCOON-1112:

      <script language="JavaScript" type="text/javascript">
      function addLoadEvent(func) { 
        var oldonload = window.onload; 
        if (typeof window.onload != 'function') { 
          window.onload = func; 
        } else { 
          window.onload = function() { 
      addLoadEvent( myJsFunction );  
      //in MS-Iexporer == if (window.attachEvent) window.attachEvent("onload", myJsFunction);

> [PATCH] Client-side: window.onload handler clobbered by <body onload="...">
> ---------------------------------------------------------------------------
>          Key: COCOON-1112
>          URL:
>      Project: Cocoon
>         Type: Bug

>   Components: Blocks: Forms
>     Versions: 2.1.8
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Mark Lundquist
>     Assignee: Cocoon Developers Team
>  Attachments: cocoon.bug28012.patch
> See:
> Granted, the transformation on the <body> element does preserve whatever JS statements
may have 
> been contained in the transformed <body>, 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 <body> element is generated by a common page stylesheet several transformations
> 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 <body>
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 <head> into
the HTML... e.g., <script 
> type="text/javascript" src="...">).  At any rate, if forms-lib.js would accomodate
(i.e., preserve) 
> window.onload, that would just be one less surprise (and one less thing to spend time
debugging) for 
> the user.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message