fixed in trunk; possible to check the fix in embedded eclipse-ie ? Just do a SVN checkout and run the maven build.
thx On 10/29/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > 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 > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
