Value not assigned in a javascript




6 years ago
6 years ago


(Reporter: nicolas.hermestroff, Unassigned)


12 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)



(4 attachments)



6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

We upgraded from Firefox 9 to 11, 12 and 13 beta. All three versions reproduced the problem. The code is :

* Sorts the types into alphabetical order.
* @param objXML The XML DOM to sort.
emxUITypeChooser.prototype.sortDOM = function (objXML) {
function _sortDOM(objXML) {
var arrTemp = new Array;
var arrTypes = emxUICore.selectNodes(objXML, "aef:type");
for (var i=arrTypes.length-1; i >= 0; i--) {
for (var i=0; i < arrTemp.length; i++) {
var objStartNode = objXML;
if (objXML.nodeType != 1) {
objStartNode = emxUICore.getElementsByTagName(objXML, "aef:root")[0];

(Please note this code is part of Enovia product from Dassault System so I can modify it since it is jsp, but not much explain it or reproduce in another example)

Actual results:

var objStartNode = objXML;

Using Firebug (and a breakpoint at the "if" following) with Firefox 9, this line shows "root" <- "Document"

With Firefox 12, this line shows "undefined" <- "Document".

I am absolutely pointless since, for the javascript I know, this "var" follow a function and should be the first line executed here (the function is called at the end with "_sortDOM(objStartNode);".

Expected results:

In my opinion, both should have referenced "root" <- "Document". Please note that the program hang after that. Firefox just showing the "working" mouse cursor and nothing happening.

Comment 1

6 years ago
Please note I did reproduced the bug on :
- Seven 64 bits
- XP 32 bits
- Seven 32 bits
Component: Untriaged → Webapp Runtime
This has nothing to do with the web runtime for desktop.
Component: Webapp Runtime → Untriaged
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
QA Contact: untriaged → general
Nicolas, is it possible to link to a complete web page showing the problem?  The code quoted in comment 0 is just a small snippet; the caller could easily be passing undefined to sortDOM().

Also, do you only see the problem in Firebug, or also if you alert() the value?

Comment 4

6 years ago
Created attachment 630107 [details]
Example 1 of the problem

Comment 5

6 years ago

I did upload an upload of :
- cap1.jpg alert() of the first value
- cap2.jpg alert() of the second value
- cap3.jpg example of the display after the execution of the problem in firebug
- 1 jsp which is the accessed page and 1 js which is where the function is (please see cap3.jpg for line numbers and stack)

alert() do send the same value but I'm unsure if it is okay since it hangs just after.
Nicolas, what are the messages you get in Firefox 9 and Firefox 11 or 12 if you change this:

        if (objXML.nodeType != 1) {
            objStartNode = emxUICore.getElementsByTagName(objXML, "aef:root")[0];


        if (objXML.nodeType != 1) {
            objStartNode = emxUICore.getElementsByTagName(objXML, "aef:root")[0];
            alert(emxUICore.getElementsByTagName(objXML, "aef:root").length);

Comment 7

6 years ago
Created attachment 630122 [details]
Result of the comment 6

please find 2 capture in the order of execution.
(In reply to Nicolas HERMESTROFF from comment #7)
> please find 2 capture in the order of execution.

Thanks! Do you get any messages in Firefox 9?

Comment 9

6 years ago
Created attachment 630143 [details]
Result of the 8th comment

You are right, I forgot to send you that. You'll find attached the screenshots for ff 3.5 and 9.

I also included the final result of the page on those two versions. With ff 12, the page do not display the "Types / Article" tree.
So the problem is here:

objStartNode = emxUICore.getElementsByTagName(objXML, "aef:root")[0];

getElementsByTagName returned a NodeList with one element in Firefox 9 and in Firefox 11 and 12 it's empty. A DOM change/bug seems more likely than a JS bug...
Could be.  But bug 492933 (which would _really_ break that) is still open.  So what actually changed?

Jan, can you reproduce?  If so, can you bisect on nightlies?
(In reply to Boris Zbarsky (:bz) from comment #11)
> Jan, can you reproduce?

No I cannot reproduce, there's not a complete testcase.

Nicolas, would it be possible to give somebody access to a website so that we can investigate the problem? If that's not possible, would you be willing to use to find out when the problem started?

You can use

mozregression --good=2011-09-26 --bad=2011-12-20

If you could paste the "Last good nightly" and "Pushlog" lines it prints at the end that would be very useful.

Comment 13

6 years ago
I'm lost.

Installing mozregression, I spent a lot understanding that he program could be install with a proxy (configured in IE or firefox) but need to be run without.

Running mozregression, I started at 12? and stopped at minefield 3.2a1pre because it never display the page correctly. I tried to uninstall my local firefox, rename the 2 mozilla folders in my user directory and run directly minefield from moznightlyapp. Every time it fails.

To be sure, I tried on another machine with official Firefox 9 and 10 (cause our 9 comes normally from Frontmotion) and 9.0.1 works, 10.0 fails.

If you have suggestion about mozregression, please give them to me.

About access to the machine, it won't be easy from outside. We use webex for those kind of access. Maybe I can organize a conference where you'll have the hand on both firefox (9 and 10) and on the JSP server pages ?

Comment 14

6 years ago
Ok, my fault. I tested mozregression on another machine (with XP and not Seven 64) and it worked. The result is :

Last good nightly: 2011-09-27
First bad nightly: 2011-09-28


Also as a test, I tried on Knoppix 6.4.4 wih Iceweasel 3.6.13 : it works. Knoppix v6.7.1 with iceweasel 6.0.2 : it works. Knoppix 7.0.2 with Iceweasel 10.0.4 : it fails
Interesting.  Nothing in there should really affect DOM behavior, but...

That range _is_ the range for the version bump.  Just to check, what happens if you run Firefox 10, but spoof the UA string to the one from Firefox 9?
To spoof the UA open about:config, confirm the warning, right click -> new-> string
name: general.useragent.override value: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0

Comment 17

6 years ago
It works.

I don't know much about this. Does it means that it is the jsp/js page that manage differently the browser ? Or is it linked to an internal engine of firefox ?
It looks like the website tries to detect whether Firefox is used, but this check probably does not handle the new two-digit version number (9 to 10). So the website may think you're using another browser and do things differently.

The emxUIDOMTypeChooser.js file you attached uses isMinMoz14 and isMoz variables. Can you attach the file where these values are defined? Is there a .js/.jsp/.inc file that contains something like "isMoz = " or "isMinMoz14 = "?

Comment 19

6 years ago
Created attachment 631294 [details]
the file with the problem

You were correct. This is the corrected file with (in comment) the problem. There is a regexp with \\d.\\d for rv: so it can't work with version after 9.9.

Thank you a lot for that, It was so simple I don't even think about it.

I'll file a bug at Dassault immediately for this bug.
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.