k, did the same there.
On 10/29/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote: > > Ehm, I've never used maven or Trinidad checkout. But placing: > > if(_agent.isIE && window.external) > > and including explicitely Core.js at the top of my pages makes everything > running just fine. > > -- Renzo > > > Matthias Wessendorf wrote: > 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
