Orbeon Forms community mailing list

Client side exception in Form Builder on IE8

Classic

List

Threaded

13 messages Options

Micael Kirouac

Client side exception in Form Builder on IE8

Hi,

I have a really strange problem with IE8 and orbeon forms 3.8.0.201005141841 PE (No problem with FF). I run Form Builder inside an IFrame with Liferay. Sometime I get an error when attempting to test the form but I could not reliably reproduce it. One of my colleague never get the error, another get it all the time and sometimes I can reproduce it while sometimes everything works fine. This is the error message I get when I can reproduce it:

SCRIPT5007: Unable to get value of the property 'parentNode': object is null or undefined
xforms-dialog-yuicalendar-min.js, line 88 character 154959

Basically, this line is the line #6967 of xforms.js ("var caseBeginParent = caseBegin.parentNode;"). The error is misleading because the code should never hit that spot (Testing with a form that contains a single textbox), it should hit the else statement instead. From now on, I will refer to the xforms.js file for line numbers).

I have debugged the issue and there seem to be some sort of synchronization problem. From my observations, here is what I think is the normal flow should be:

1.Inside the Form Builder, The Test button is pressed.
2.DomFocusIn and DomActivate events are dispatched to the server
3.The server reply and tell the client to run a script "xf_2793_xforms_function". That script is responsible for creating the test window.
4.When the client is ready, the "show-fb-test-dialog" event is dispatched to the server
5.The server reply and the client start rendering the xform inside the dialog.

This is the expected behavior, sometimes there seem to be a problem where #5 is actually executing before #4 (or at the same time, not sure). The error is actually coming from handleResponseDom when handling reply from #5.

It seem that code from line #6951 (" // "div" elements for xforms:switch and xxforms:dialog") is actually called befor the modal window is created. That part of code do different processing depending if the target is a switch or dialog (in the case here is should be the dialog that hold the test form). To find out if it is a dialog, the following variable is tested for null: "var yuiDialog = ORBEON.xforms.Globals.dialogs[controlId];". Usually, this represent the fb-test-dialog control and the "else //this is a dialog" is hit. Unfortunately, sometimes in IE, the test fails and the code fall into the "if (yuiDialog == null)" code block, actually crashing at " var caseBeginParent = caseBegin.parentNode;" because of course caseBegin does not exists.

I am out of ideas on what is the real cause and how I can fix this. To compare with to the flow described above, here is what seem to actually happen when I see this error:

1.Inside the Form Builder, The Test button is pressed.
2.DomFocusIn and DomActivate events are dispatched to the server
3.The server reply and tell the client to run a script "xf_2793_xforms_function", for some reason, execution of that script is delayed.
4.The client is not ready but he send the "show-fb-test-dialog" event to the server
5.The server reply and the client attempt start rendering the xform inside the dialog but the dialog does not exists, resulting in a crash.

Thank you for your time.

Erik Bruchez

Re: Client side exception in Form Builder on IE8

Administrator

Thanks for the detailed investigation. The bad part is that this is
from a two year-old version. Does it happen with 3.9.1 ?

-Erik

On Mon, May 7, 2012 at 11:44 AM, Micael Kirouac
<[hidden email]> wrote:

> Hi,
>
> I have a really strange problem with IE8 and orbeon forms 3.8.0.201005141841
> PE (No problem with FF). I run Form Builder inside an IFrame with Liferay.
> Sometime I get an error when attempting to test the form but I could not
> reliably reproduce it. One of my colleague never get the error, another get
> it all the time and sometimes I can reproduce it while sometimes everything
> works fine. This is the error message I get when I can reproduce it:
>
> SCRIPT5007: Unable to get value of the property 'parentNode': object is null
> or undefined
> xforms-dialog-yuicalendar-min.js, line 88 character 154959
>
> Basically, this line is the line #6967 of xforms.js ("var caseBeginParent =
> caseBegin.parentNode;"). The error is misleading because the code should
> never hit that spot (Testing with a form that contains a single textbox), it
> should hit the else statement instead. From now on, I will refer to the
> xforms.js file for line numbers).
>
> I have debugged the issue and there seem to be some sort of synchronization
> problem. From my observations, here is what I think is the normal flow
> should be:
>
> 1.Inside the Form Builder, The Test button is pressed.
> 2.DomFocusIn and DomActivate events are dispatched to the server
> 3.The server reply and tell the client to run a script
> "xf_2793_xforms_function". That script is responsible for creating the test
> window.
> 4.When the client is ready, the "show-fb-test-dialog" event is dispatched to
> the server
> 5.The server reply and the client start rendering the xform inside the
> dialog.
>
> This is the expected behavior, sometimes there seem to be a problem where #5
> is actually executing before #4 (or at the same time, not sure). The error
> is actually coming from handleResponseDom when handling reply from #5.
>
> It seem that code from line #6951 (" // "div" elements for xforms:switch and
> xxforms:dialog") is actually called befor the modal window is created. That
> part of code do different processing depending if the target is a switch or
> dialog (in the case here is should be the dialog that hold the test form).
> To find out if it is a dialog, the following variable is tested for null:
> "var yuiDialog = ORBEON.xforms.Globals.dialogs[controlId];". Usually, this
> represent the fb-test-dialog control and the "else //this is a dialog" is
> hit. Unfortunately, sometimes in IE, the test fails and the code fall into
> the "if (yuiDialog == null)" code block, actually crashing at " var
> caseBeginParent = caseBegin.parentNode;" because of course caseBegin does
> not exists.
>
> I am out of ideas on what is the real cause and how I can fix this. To
> compare with to the flow described above, here is what seem to actually
> happen when I see this error:
>
>
> 1.Inside the Form Builder, The Test button is pressed.
> 2.DomFocusIn and DomActivate events are dispatched to the server
> 3.The server reply and tell the client to run a script
> "xf_2793_xforms_function", for some reason, execution of that script is
> delayed.
> 4.The client is not ready but he send the "show-fb-test-dialog" event to the
> server
> 5.The server reply and the client attempt start rendering the xform inside
> the dialog but the dialog does not exists, resulting in a crash.
>
> Thank you for your time.
>
> --
> View this message in context: http://orbeon-forms-ops-users.24843.n4.nabble.com/Client-side-exception-in-Form-Builder-on-IE8-tp4615518.html
> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Micael Kirouac

Re: Client side exception in Form Builder on IE8

Well I don't think upgrading to 3.9 is really an option, I would really need to find a fix for this on 3.8.

Erik Bruchez

Re: Re: Client side exception in Form Builder on IE8

Administrator

If you do reproduce it on 3.9 (or even better with a nightly build),
we can certainly look at it, and with luck the fix can be backported
to 3.8. If it is a 3.8-only issue, then that will require a support
plan for us to look at it.

Is there any way you can try it with 3.9.1?

-Erik

On Tue, May 8, 2012 at 7:45 AM, Micael Kirouac <[hidden email]> wrote:

> Well I don't think upgrading to 3.9 is really an option, I would really need
> to find a fix for this on 3.8.
>
> --
> View this message in context: http://orbeon-forms-ops-users.24843.n4.nabble.com/Client-side-exception-in-Form-Builder-on-IE8-tp4615518p4617689.html
> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>

Re: Re: Client side exception in Form Builder on IE8

This post was updated on .

Caveat: I have no experience in the problem posted ..

but if the original poster had a spare USB drive available perhaps he could

install live CD ubuntu OS (with persistence) on the USB drive

install tomcat7

install orbeon nightly build

...

If this is an option to build a "sandbox" here are some installation tips ...

http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/

http://www.pendrivelinux.com/what-is-persistent-linux/

...

[p.s.] I've just realised that probably (with IE8) the current xforms system is running on windows OS.

Linux doesn't come with IE8. Quote: "(No problem with FF)"

So .. would enabling YUILogger help to pin down the issue?

http://developer.yahoo.com/yui/logger/

Micael Kirouac

Re: Client side exception in Form Builder on IE8

This post was updated on .

In reply to this post by Micael Kirouac

I don't know if I will be able to test this with 3.9. I am really trying hard to fix this for 3.8.

In the meanwhile, I have found some more information and I think that with some help I might be able to find the solution myself. My assumption that the two event calls were not synchronized was not correct. The actual reason is that the ORBEON.xforms.globals.dialogs somehow isn't initialized. When this error happens, the sequence of execution is correct: I could finally verify this because the IE debugger tend to make the problem go away (maby this is a hint?). There are no errors in step #2 because the script uses YAHOO.util.Dom.get("fb-test-dialog"); and does not refer to ORBEON.xforms.globals.dialogs while #5 get the dialog from ORBEON.xforms.globals.dialogs instead of YAHOO.util.Dom.get("fb-test-dialog");.

So I would like to know where does the ORBEON.xforms.globals.dialogs get initialized? I have searched around but could't find it. If I can find where this get initialized I could find out why it is not, and hopefully find a solution.

...

[edit]: I just see that part about YUI2 Logger, I will definitely try this!

Erik Bruchez

Re: Re: Client side exception in Form Builder on IE8

Administrator

Micael,

Have you had a chance to play with 3.9.x?

-Erik

On Tue, May 8, 2012 at 3:48 PM, Micael Kirouac <[hidden email]> wrote:

> I don't know if I will be able to test this with 3.9. I am really trying hard
> to fix this for 3.8.
>
> In the meanwhile, I have found some more information and I think that with
> some help I might be able to find the solution myself. My assumption that
> the two event calls were not synchronized was not correct. The actual reason
> is that the ORBEON.xforms.globals.dialogs somehow isn't initialized. When
> this error happens, the sequence of execution is correct: I could finally
> verify this because the IE debugger tend to make the problem go away (maby
> this is a hint?). There are no errors in step #2 because the script uses
> YAHOO.util.Dom.get("fb-test-dialog"); and does not refer to
> ORBEON.xforms.globals.dialogs while #5 get the dialog from
> ORBEON.xforms.globals.dialogs instead of
> YAHOO.util.Dom.get("fb-test-dialog");.
>
> So I would like to know where does the ORBEON.xforms.globals.dialogs get
> initialized? I have searched around but could't find it. If I can find where
> this get initialized I could find out why it is not, and hopefully find a
> solution.
>
> --
> View this message in context: http://orbeon-forms-ops-users.24843.n4.nabble.com/Client-side-exception-in-Form-Builder-on-IE8-tp4615518p4618932.html
> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>

Micael Kirouac

Re: Re: Client side exception in Form Builder on IE8

Yes I have played with 3.9 and the problem seem to be fixed. I would like to avoid upgrading to 3.9 and I think I found a way to fix 3.8 by doing some deeper debugging and comparing with 3.9: I finally managed to find the exact cause of this behavior.

Let me explain. In 3.9, there is a property called "oxf.xforms.resources.javascript-at-bottom" which does not exist in 3.8. For 3.8, it put all the javascript at the bottom per the theme.xsl files.

So what is the problem with scripts at the bottom of the page? Well, for some obscure reasons IE can sometime execute the global JS code after DomReady event. The result: Orbeon is initialized (in DomReady event handler) without the orbeonInitData (which is set by global code).

When the problem occur, the orbeonInitData is set right after the DomReady execution and then IE decides to run the global JS code. This is the root cause of the crash since the dialogs (among other stuff) aren't initialized because the DomReady event handler check for orbeonInitData and if it's undefined it completely skips that part of the initialization.

I have compared with a 3.9 installation and I get the scripts in the meta data of the web page which seems to solve the problem. When I think about it now, it makes some sense because in 3.8 the scripts aren't really part of the DOM document. There is even a note in theme.xsl that say "it's not valid XML but yahoo guide suggest to do that".

What I would like to do now to avoid upgrading to 3.9 is to change the theme.xsl file to put the scripts in the metadata or somewhere else in the page. Are there any possible side-effects I should be aware of? Knowing what the problem is, do you have any suggestions?

And one last note, this problem might be reproductible on 3.9 with the "oxf.xforms.resources.javascript-at-bottom" property set to true.

Thank you for your support.

Erik Bruchez

Re: Re: Re: Client side exception in Form Builder on IE8

Administrator

Micael,

Great to hear! And this happens within an iframe only under IE 8, right?

There is no problem moving the scripts back to the HTML <head>
element. The reason to put them at the bottom is strictly to improve
page loading performance.

-Erik

On Thu, May 10, 2012 at 6:02 AM, Micael Kirouac
<[hidden email]> wrote:

> Yes I have played with 3.9 and the problem seem to be fixed. I would like to
> avoid upgrading to 3.9 and I think I found a way to fix 3.8 by doing some
> deeper debugging and comparing with 3.9: I finally managed to find the exact
> cause of this behavior.
>
> Let me explain. In 3.9, there is a property called
> "oxf.xforms.resources.javascript-at-bottom" which does not exist in 3.8. For
> 3.8, it put all the javascript at the bottom per the theme.xsl files.
>
> So what is the problem with scripts at the bottom of the page? Well, for
> some obscure reasons IE can sometime execute the global JS code *after*
> DomReady event. The result: Orbeon is initialized (in DomReady event
> handler) without the orbeonInitData (which is set by global code).
>
> When the problem occur, the orbeonInitData is set right after the DomReady
> execution and then IE decides to run the global JS code. This is the root
> cause of the crash since the dialogs (among other stuff) aren't initialized
> because the DomReady event handler check for orbeonInitData and if it's
> undefined it completely skips that part of the initialization.
>
> I have compared with a 3.9 installation and I get the scripts in the meta
> data of the web page which seems to solve the problem. When I think about it
> now, it makes some sense because in 3.8 the scripts aren't really part of
> the DOM document. There is even a note in theme.xsl that say "it's not valid
> XML but yahoo guide suggest to do that".
>
> What I would like to do now to avoid upgrading to 3.9 is to change the
> theme.xsl file to put the scripts in the metadata or somewhere else in the
> page. Are there any possible side-effects I should be aware of? Knowing what
> the problem is, do you have any suggestions?
>
> And one last note, this problem might be reproductible on 3.9 with the
> "oxf.xforms.resources.javascript-at-bottom" property set to true.
>
> Thank you for your support.
>
> --
> View this message in context: http://orbeon-forms-ops-users.24843.n4.nabble.com/Client-side-exception-in-Form-Builder-on-IE8-tp4615518p4623443.html
> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com.
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>

Micael Kirouac

RE: Re: Re: Client side exception in Form Builder on IE8

Yes our setup is as follow:

We have a vaadin portlets running inside Liferay. To run FormBuilder inside vaadin, we run it inside an iframe.

I am still trying to make it work while moving the scripts at the top, but it seem that IE dosen’t like that either. The form builder does not always load and when it does, the buttons (test/save/publish) does not react. It’s like if scripts were now executing too soon.

I am thinking that maybe leaving all the scripts at the bottom except the orbeonInitData might work. Now I just have to find a way to do that with my limited xsl knowledge..

I am still wondering why it work with 3.9 tough (with all scripts in the head) I think I will compare the output html of both versions again. Any thoughts?

From: Erik Bruchez [via Orbeon Forms (ops-users)] [mailto:[hidden email]]
Sent: May-10-12 12:27 PM
To: Micael Kirouak
Subject: Re: Re: Re: Client side exception in Form Builder on IE8

If you reply to this email, your message will be added to the discussion below:

http://orbeon-forms-ops-users.24843.n4.nabble.com/Client-side-exception-in-Form-Builder-on-IE8-tp4615518p4623928.html

To unsubscribe from Client side exception in Form Builder on IE8, click here.
NAML

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2171 / Virus Database: 2425/4989 - Release Date: 05/10/12

Micael Kirouac

RE: Re: Re: Client side exception in Form Builder on IE8

Ok I finally found the solution. Any feedbacks/suggestions?

I modified the theme-plain.xsl and replaced the part that copy the scripts at the bottom of the page. I could not make it work with the scripts in the head and I don't really understand why (any clues?). It seem that with the scripts in the head, the DomReady event of yui is executed way before the dom document is ready, resulting in a bunch of javascript errors and a blank page. The solution I found copy the orbeonInitData script in the head and keep everything else after the body tag. This involve two for-each to copy the scripts:

In the head:

<xsl:for-each select="/xhtml:html/xhtml:head/xhtml:script[starts-with(., 'var orbeonInitData')]">
<xsl:element name="xhtml:{local-name()}" namespace="{namespace-uri()}">
<xsl:apply-templates select="@*|node()"/>
</xsl:element>
</xsl:for-each>

and after the body:

<xsl:for-each select="/xhtml:html/xhtml:head/xhtml:script[not(starts-with(., 'var orbeonInitData'))]">
<xsl:element name="xhtml:{local-name()}" namespace="{namespace-uri()}">
<xsl:apply-templates select="@*|node()"/>
</xsl:element>
</xsl:for-each>

After this modification, I was unable to reproduce the problem and the report builder always load correctly.

Micael Kirouac wrote

Yes our setup is as follow:

We have a vaadin portlets running inside Liferay. To run FormBuilder inside vaadin, we run it inside an iframe.

I am still trying to make it work while moving the scripts at the top, but it seem that IE dosen't like that either. The form builder does not always load and when it does, the buttons (test/save/publish) does not react. It's like if scripts were now executing too soon.

I am thinking that maybe leaving all the scripts at the bottom except the orbeonInitData might work. Now I just have to find a way to do that with my limited xsl knowledge..

I am still wondering why it work with 3.9 tough (with all scripts in the head) I think I will compare the output html of both versions again. Any thoughts?

Micael Kirouac

RE: Re: Re: Client side exception in Form Builder on IE8

Actually doing this break the forms in FF..

Is there a way to serve a specific theme.xsl for IE only?

From: Micael Kirouac [via Orbeon Forms (ops-users)] [mailto:[hidden email]]
Sent: May-11-12 10:36 AM
To: Micael Kirouak
Subject: RE: Re: Re: Client side exception in Form Builder on IE8

Erik Bruchez

Re: RE: Re: Re: Client side exception in Form Builder on IE8

Administrator

On Fri, May 11, 2012 at 11:08 AM, Micael Kirouac
<[hidden email]> wrote:
> Actually doing this break the forms in FF..

The issue might be deeper than initially thought.

> Is there a way to serve a specific theme.xsl for IE only?

Not magically. You will have to check the user agent and decide based on that.

The epilogue is passing some parts of the request to the theme:

https://github.com/orbeon/orbeon-forms/blob/master/src/resources-packaged/config/epilogue-servlet.xpl#L38

You could replace in there:

<include>/request/headers/header[name = 'accept']</include>

with:

<include>/request/headers/header[name = ('accept', 'user-agent')]</include>

Then, from the theme:

doc('input:request')/*/headers/header[name = 'user-agent']/value

returns the user agent.

The issue now is to determine whether it's IE!

We have some code doing that written in Java (now Scala):

https://github.com/orbeon/orbeon-forms/blob/master/src/java/org/orbeon/oxf/util/UserAgent.java

But you can't easily call this directly from XSTL because you need the request…

Still, the sniffing logic could be rewritten in XSLT.

But doing this on the server is a bit fragile anyway. It would be best
to figure this out on the client.

-Erik

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws