100703 - Web-Site not working (problem with js dom indexing)

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[frank schaefer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091303

in the site http://www.mlp.de - when clicking on one of the hyperlinks - there
is no forwarding to the approriate subsites - compared to Netscape 4.7 and M$IE
5.x where it all works fine.

I don't know if is a problem of Mozilla or the web-site, but it is the last
remaining website i'm using frequently i have to use other browsers for

Reproducible: Always
Steps to Reproduce:
1.www.mlp.de
2.clicking on one of the hyperlinks
3. no forwarding

Actual Results:  nothing

Expected Results:  should forward to a subsite (compare to Nertscape 4.7x or msIE)

Comment 1

[Warner Young]

Confirming that the hyperlinks aren't working (build 2001091903, Win98) but does
work in NS 4.x.  Since they use Javascript, maybe a JS problem?

Comment 2

[Boris Zbarsky [:bzbarsky]]

no, the JS seems to be working fine... at a guess, this is a cookie problem.

Comment 3

[Stephen P. Morse]

Confirming.  But I don't think it's a cookie problem.  I'll investigate further 
and determine what component is at fault.

Comment 4

[Stephen P. Morse]

Sorry, Boris, you were wrong -- the JS is not working fine.

After carefully investigating it and even creating a local copy of the website, 
I was able to determine that it is a javascript dom problem.

I'm attaching the local copy of the website.  It consists of two files: bug.htm 
which is the site itself and XPFramework.js.  Note that I've added some "dump" 
statements to the JS file so I could see what is going on.

The values that are supposed to be dumped out are as follows:

   formObj.elements[0]:  name="portal"     value="7"
   formObj.elements[1]:  name="~login"     value="DEF_STD"
   formObj.elements[2]:  name="~template"  value="start"
   formObj.elements[3]:  name="baseurl"    value="http://...."
   formObj.elements[4]:  name="language"   value="DE"

But instead I am getting:

   formObj.elements[0]:  name="portal"     value="7"
   formObj.elements[1]:  name="~template"  value="DEF_STD"
   formObj.elements[2]:  name="baseurl"    value="http://...."
   formObj.elements[3]:  name="language"   value="DE"
   formObj.elements[4]:  name="~login"     value=""

What's happening is that the numeric indexing of the elements in the form are 
not correct.  The form has "~login" as the second element (see the attached html 
file) but it is being indexed as the last one.  And the javascript at the site 
is trying to set a value for it with:

   formObj.elements[1].value=roleName[portalIndex];

so it is setting "~template" instead of "~login".  If you change the index of 
[1] to [4] in the local copy of the website(see the attached js file), 
everything works fine.

Comment 5

[Stephen P. Morse]

Attachment: local copy of website: bug.htm

Comment 6

[Stephen P. Morse]

Attachment: local copy of website: XPFramework.js

Comment 7

[Stephen P. Morse]

Reassigning to javascript

Comment 8

[Stephen P. Morse]

Just to clarify.  When I said:

   If you change the index of [1] to [4] in the local copy of the website

I was referring to the index in the statement shown immediately before that 
sentence.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Over to DOM0.  ccing jkeiser because he's working on this sorta stuff... :)

Comment 10

[John Keiser (jkeiser)]

It would help a *lot* in debugging this if you could reduce the testcase. 
Basically what this means is, isolate the problem down to just the
essentials--in this case, I think it would be:
- a simple <SCRIPT>function openPortal() ...</SCRIPT> at the top (external js is
OK if you must, but try and make the URL to the JS file be the bugzilla
attachment so that we can test straight from the bug).
- the form
- one clickable HREF
- possibly the dump statement

This is my guess based on discussion.

On another note, I can tell that clicking on these hyperlinks goes back to the
main page, but I don't see any kind of dump happening here ... ?

Thanks!

Comment 11

[Stephen P. Morse]

Sure, go ahead and reduce the test case.  It's your bug now so you can do 
whatever you want with it.

Comment 12

[Stephen P. Morse]

Here's some more information.  The indexing gets destroyed if you rename one of 
the elements.  And that is exactly what the website was doing.

The following simplified excerpt from the original site will display "one" both 
time on both Nav 4 and IE whereas it will display "one" and then "two" on N6.

<html>
  <head>
    <script>
      function ShowIt() {
        alert('element[1]='+ document.portalInput.elements[1].name);
        document.portalInput.elements[1].name="one";
        alert('element[1]='+ document.portalInput.elements[1].name);
      }
    </script>
  </head>
  <body>
    <form name="portalInput" >
      <input type="hidden" name="zero">       
      <input type="hidden" name="one">  
      <input type="hidden" name="two">
      <input type="hidden" name="three">
      <input type="hidden" name="four">
      <input type="button" value="press me" onclick="ShowIt()">
    </form>
  </body>
</html>

Comment 13

[Johnny Stenback (:jst)]

This is due to us not properly sorting items in form.elements, I'm not sure if
jkeiser is planning on fixing this yet or not.

Comment 14

[John Keiser (jkeiser)]

I reduced the testcase too :)  Attaching.

The problem specifically is, we add the element to the end of the elements array
whenever we set the name.

Comment 15

[John Keiser (jkeiser)]

Attachment: Reduced testcase

Comment 16

[John Keiser (jkeiser)]

I doubt this fix is going in as part of bug 34297--it's not relevant enough. 
The major problem is that there is no way to insert a control into a specific
index in form.elements[].  form.insertChild() should fail to work properly as well.

Comment 17

[Johnny Stenback (:jst)]

Pushing to mozilla0.9.7

Comment 18

[Johnny Stenback (:jst)]

I bet the patch in bug 109854 fixes this problem too.

Comment 19

[Johnny Stenback (:jst)]

Looks like this is fixed now.

Comment 20

[Prashant Desale]

Verified with 2003-04-25-12-1.3.1 on winXP.