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=""/>
</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
|
