Firefox 3.5: JIT-Error? -- Workaround for script errors with Firefox 3.5 / Opencms 7.0.5, 7.5

[Christian Steinert]

Dear All,

I just wanted to let you know:

I have deactivated Firefox's new just-in-time compiler by going to about:config and setting javascript.options.jit.content to false.
After restarting Firefox and going back into opencms, the opencms explorer works again as it should be.

I am afraid though, that I won't have time to narrow the problem down and create a minimal test case for the Firefox guys so that this can be reported as a bug to them. Does anybody have time to narrow this down and eport it, so that Firefox can be fixed?

Best Regards
Christian

> > There is even more strangeness with Firefox 3.5. As Achim already mentioned,
> > there may be timing issues with Firefox' increased javascript performance.
> > And indeed, a lot of our Ajax scripts started behaving strangely. More
> > commonly, XMLHttpRequest seems to behave differently now with Firefox 3.5,
> > especially if you work on localhost. There is a big difference in what works
> > and what not depending on what server you are working on (local or remote).
>
> What you describe sounds like some sort of race condition to me.
>
> FF3.5 has changed the way how parsing interacts with javascript (called speculative parsing): HTML parsing does not block anymore, while Javascript files are loaded and then later, things like document.write(...) are patched into already parsed DOM tree.
>
>
> But the script error that I get is "subnode is undefined":
>
>   function getNodeIdByName(nodeName) {
>   ....
>      for (i=0; i<childs.length; i++) {
>          subnode = tree.nodes[childs[i]];
>          var subname = result + subnode.name;
>
>
> Having subnode be undefined there is rather weird.
> Both tree.nods and childs contain proper data. For entries in childs, there seems to be a corresponding entry in tree.nodes. And all entries in tree.nodes have a name property. So I really don't know what is wrong there. It all looks right
>
> Sadly, the Javascript debugger of Firebug also seems to have a few issues in Firefox 3.5 right now, so some things behave a little strange (the source code location, where the degugger is at, is not shown properly, when stopping at a break point).
>
> But the opencms-Javascript seems to be fine and the data also seems to be right, too.
>
> Weird indeed :(
>
> Best regards
> Christian
> ______________________________________________________
> GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://movieflat.web.de
>
>
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
>

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de


_______________________________________________
This mail is sent to you from the opencms-dev mailing list
To change your list options, or to unsubscribe from the list, please visit
http://lists.opencms.org/mailman/listinfo/opencms-dev

Hi Christian,

thx for your effort. Exactly that part of tee.js has been changed,
checked in and works on my box now.


Kind Regards,
Achim.

-------------------
Achim Westermann

Alkacon Software GmbH  - The OpenCms Experts
http://www.alkacon.com - http://www.opencms.org





Christian Steinert schrieb:

> Dear All,
>
> I just wanted to let you know:
>
> I have deactivated Firefox's new just-in-time compiler by going to about:config and setting javascript.options.jit.content to false.
> After restarting Firefox and going back into opencms, the opencms explorer works again as it should be.
>
> I am afraid though, that I won't have time to narrow the problem down and create a minimal test case for the Firefox guys so that this can be reported as a bug to them. Does anybody have time to narrow this down and eport it, so that Firefox can be fixed?
>
> Best Regards
> Christian
>
>
>
>>> There is even more strangeness with Firefox 3.5. As Achim already mentioned,
>>> there may be timing issues with Firefox' increased javascript performance.
>>> And indeed, a lot of our Ajax scripts started behaving strangely. More
>>> commonly, XMLHttpRequest seems to behave differently now with Firefox 3.5,
>>> especially if you work on localhost. There is a big difference in what works
>>> and what not depending on what server you are working on (local or remote).
>> What you describe sounds like some sort of race condition to me.
>>
>> FF3.5 has changed the way how parsing interacts with javascript (called speculative parsing): HTML parsing does not block anymore, while Javascript files are loaded and then later, things like document.write(...) are patched into already parsed DOM tree.
>>
>>
>> But the script error that I get is "subnode is undefined":
>>
>>   function getNodeIdByName(nodeName) {
>>   ....
>>      for (i=0; i<childs.length; i++) {
>>          subnode = tree.nodes[childs[i]];
>>          var subname = result + subnode.name;
>>
>>
>> Having subnode be undefined there is rather weird.
>> Both tree.nods and childs contain proper data. For entries in childs, there seems to be a corresponding entry in tree.nodes. And all entries in tree.nodes have a name property. So I really don't know what is wrong there. It all looks right
>>
>> Sadly, the Javascript debugger of Firebug also seems to have a few issues in Firefox 3.5 right now, so some things behave a little strange (the source code location, where the degugger is at, is not shown properly, when stopping at a break point).
>>
>> But the opencms-Javascript seems to be fine and the data also seems to be right, too.
>>
>> Weird indeed :(
>>
>> Best regards
>> Christian
>> ______________________________________________________
>> GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
>> Jetzt freischalten unter http://movieflat.web.de
>>
>>
>> _______________________________________________
>> This mail is sent to you from the opencms-dev mailing list
>> To change your list options, or to unsubscribe from the list, please visit
>> http://lists.opencms.org/mailman/listinfo/opencms-dev
>>
>
>
> ______________________________________________________
> GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://movieflat.web.de
>
>
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev

_______________________________________________
This mail is sent to you from the opencms-dev mailing list
To change your list options, or to unsubscribe from the list, please visit
http://lists.opencms.org/mailman/listinfo/opencms-dev

[Christian Steinert]

Achim Westermann wrote:
> Hi Christian,
>
> thx for your effort. Exactly that part of tree.js has been changed,
> checked in and works on my box now.
>  
>  
Dear Achim

thanks a lot for creating a workaround so quickly (works like a charm,
but please also see my remark at the end).
________________

For everyone:

- the adjusted version of tree.js can be downloaded from:
http://cvs.opencms.org/viewvc.cgi/*checkout*/opencms/modules/org.opencms.workplace.explorer/resources/system/workplace/resources/commons/tree.js?revision=1.11

- This file needs to be uploaded into the following opencms folder and
then published:
/system/workplace/resources/commons/


After that, things seem to work well with Firefox 3.5. The change is
small and has no risk of breaking anything. The updated file does not
only work with opencms 7.5 but also with 7.0.5.
_______________

@Achim - as an aside: (I hope that it is ok to point out the following,
since I also did not know this very until recently and indeed really few
people seem to do know this):
 
The comparison if( subnode != null ) does work, but it does work only
for very peculiar reasons: This comparison checks, if foo has the
opposite truthyness of "null". Objects are "truthy" and null is "falsy",
so the check indirectly leads to the expected result, if subnode is
indeed null. But values that are not declared or that were never set to
anything, do _not_ have the value null in javascript, they have the
value undefined. And if subnode has the value undefined then any
comparison of subnote with something else will be false, even
"if(subnode == null)" would be false. This means that in the end, the
behavior of if( subnode != null ) is as one would expect, but for the
horrible reason that various javascript specification weirdnesses cancel
each other out and in the end lead to a false illusion of sanity where
the language does not actually provide it. The more straightforward
check would be to just write: if( subnode ) This will be true, if
subnode is: a non-null object, a variable that is not undefined (as
noted before, there is difference between undefined and null), or any
other "truthy" value (like a non-empty string). Therefore, this check,
will too protect against both null and undefined, but for more sane reasons.
 
A short explanation of this is available at:
http://saladwithsteve.com/2008/02/javascript-undefined-vs-null.html

Generally, it is not a good idea to do comparison against null in
Javascript, unless one also compares against undefined. Better check a
variable's truthyness directly in such cases, if possible.
On the other hand, if exact comparison is required (e.g. for comparing
two strings or two numbers), then it is cleaner and much faster to use
the not very widely used === and !== operators.

I found Douglas Crockford's videos about javascript (e.g.
http://video.yahoo.com/watch/111593) very helpful for understanding
these kinds of issues. Also, his jslint tool (jslint.com) is invaluable.
He also wrote a book on Javascript a while ago, which I haven't read but
which I would expect to be good.

Best Regards
Christian

_______________________________________________
This mail is sent to you from the opencms-dev mailing list
To change your list options, or to unsubscribe from the list, please visit
http://lists.opencms.org/mailman/listinfo/opencms-dev