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

VERIFIED FIXED in mozilla0.9.8



DOM: Core & HTML
16 years ago
15 years ago


(Reporter: frank schaefer, Assigned: jst)



Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [HAVE FIX], URL)


(3 attachments)



16 years ago
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:
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

16 years ago
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?
no, the JS seems to be working fine... at a guess, this is a cookie problem.
Assignee: pchen → morse
Component: XP Apps → Cookies
QA Contact: sairuh → tever

Comment 3

16 years ago
Confirming.  But I don't think it's a cookie problem.  I'll investigate further 
and determine what component is at fault.
Ever confirmed: true
Target Milestone: --- → mozilla0.9.5

Comment 4

16 years ago
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:


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

16 years ago
Created attachment 50266 [details]
local copy of website: bug.htm

Comment 6

16 years ago
Created attachment 50268 [details]
local copy of website: XPFramework.js

Comment 7

16 years ago
Reassigning to javascript
Assignee: morse → rogerl
Component: Cookies → Javascript Engine
QA Contact: tever → pschwartau
Summary: Web-Site not working → Web-Site not working (problem with js dom indexing)

Comment 8

16 years ago
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 
Over to DOM0.  ccing jkeiser because he's working on this sorta stuff... :)
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale
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 ... ?


Comment 11

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

Comment 12

16 years ago
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.

      function ShowIt() {
        alert('element[1]='+ document.portalInput.elements[1].name);
        alert('element[1]='+ document.portalInput.elements[1].name);
    <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()">

Comment 13

16 years ago
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.
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.
Created attachment 50312 [details]
Reduced testcase
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.
Keywords: testcase


16 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 17

16 years ago
Pushing to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 18

16 years ago
I bet the patch in bug 109854 fixes this problem too.
Whiteboard: [HAVE FIX]


16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 19

16 years ago
Looks like this is fixed now.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 20

15 years ago
Verified with 2003-04-25-12-1.3.1 on winXP.
You need to log in before you can comment on or make changes to this bug.