Hi, I noticed on an internal bug, that in some cases the "external" can be null... I was using a work around, provided by M$.
I'll fix the external issue soon. -M On 10/29/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > The reported bugfix refers to 1.0.2 js sources, I apologize for misleading. > There is still a js bug however, in Core.js line #1746 (it's reported as a > TRINIDAD-704 fix): > > window.external.AutoCompleteSaveForm(form); > > it seems that window.external is undefined for an embedded browser. > Extending the previous "if" fixes this error. > > -- Renzo > > > Renzo Tomaselli wrote: > Hi, finally I discovered that there is a js bug in Core.js, function > _validateInline: it should check for arg "validators" non being undefined. > This function is called by form validation code inserted in pages on the > fly. > Adding: > > if (!validators) > return (failureArray.length == 0); > > fixes all. > For unknown reasons, on the embedded browser this error prevents submitting > completion, while on standalone browsers it does not. > And yes, Firebug signals it properly. > > -- Renzo > > Renzo Tomaselli wrote: > No errors whatsoever but AFAIK IE6 does not report js errors, it simply > stops to render properly. > I could observe a different behavior on links since after clicking on them > I can hear the typical "click" of IE while a request is being processes. > Contrarywise - no effect after clicking buttons. > However no breakpoint is reached (such as on a PhaseListener or on any view > processing Trinidad/Facelets method.). > I could try to debug submitForm() the hard way (window.status, alert, etc.) > but I don't know how to detach involved parts of Common1_0_3.js which > appears to be generated on the fly by merging several js sources. > > -- Renzo > > Matthias Wessendorf wrote: > ha! that is really strange. > any kind of JS-error show by that beast ? > > -M > > On 10/27/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > > Hi, I wonder if anybody succeeded to run a Trinidad 1.0.3-based > application on the browser embedded in Eclipse, version 3.3 (latest) for > Windows (or even 3.2). > Trinidad 1.0.2 runs fine, while 1.0.3 does not. A simple page like this: > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > <tr:document xmlns:tr="http://myfaces.apache.org/trinidad";> > <tr:form id="login"> > <tr:commandButton text="hi" action="#{testBean.action}"/> > </tr:form> > </tr:document> > > does not submit anything to the server from such browser. No action, no > errors. Just flipping the jar pair trinidad-impl/api between 1.0.2 and > 1.0.3 makes this problem flipping as well. No cache involved. > I guess the problem is somewhere in js method submitForm(), but there is > no client-side debugging available. Also I noticed that links do submit > something, but Trinidad/Facelets machinery is not reached. Buttons do > not even fire any request. > Funny enough, FF 2.0, IE 6/7 have no problems. I read that the Eclipse > embedded browser should be IE6, however IE6 runs fine while taken > standalone. > > -- Renzo > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
