Closed Bug 154211 Opened 22 years ago Closed 22 years ago

eFax "Contact Us" page doesn't work

Categories

(Core :: DOM: Navigation, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mozilla.org, Assigned: radha)

References

()

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020620
BuildID:    2002062004

On this page, there are two selection lists, one labelled "*Category (please
choose):" and the other "*Subject (please choose):".  When you select an entry
in the first list, the 2nd one should be updated with a new list of choices.  On
Mozilla, it doesn't work.

For instance, in Internet Explorer, if I select "Billing Questions" for the
Category, the Subject list gives me these options:

- Please Choose -
Service Charges
Questions Regarding Invoices
Questions/Problems with Credit Cards
Pricing
Other Billing Questions



Reproducible: Always
Steps to Reproduce:
1. Select a Category
2. Try to select a Subject

Actual Results:  There is only one choice for Subject, and it says, "Please
Choose a Category Above"

Expected Results:  It should have given me a list of choices

This works in IE6 and Netscape 4.7.  I'm assuming it's a JavaScript bug because
on JavaScript can modify a selection list dynamically.
Confirming bug with Mozilla trunk binary 20020617xx on WinNT.
Here's what's happening. The "Category" selection list is given by

<select name="inquiryCategory" size="1"
        onChange="updateList(this.form, this.options[selectedIndex].value,
                             this.form.inquirySubject.length)">


I chose Category = "Questions About Plus Service". In the Mozilla
JS Debugger, I verified that all the updateList() function works as
expected, up until the last line:

----------------------  JS DEBUGGER SESSION  ------------------------
var sel = theForm.inquirySubject
[HTMLSelectElement] [class: HTMLSelectElement] {0}
var opts = sel.options

opts[0].value
$[4] = [string] "None"
opts[1].value
$[5] = [string] "General Information About Plus Service"
opts[2].value
$[6] = [string] "How To Send From Email"
opts[3].value
$[7] = [string] "Problems Signing Up For Plus Service"
---------------------------------------------------------------------


And so forth - all the proper values for the "Subject" list.
But then for some reason, if the browser is Netscape they 
do 
                      history.go(0);


Here is the function:

function updateList(theForm, catName, subjListLength){
  for (var i=subjListLength + 1 ; i > 0 ; i-- )
  {
	       etc.
               etc.
  }
                                   <<<--- UP TO HERE, THINGS ARE PERFECT
  if (browser_type=="Netscape")    
     history.go(0);                <<<--- THIS CAUSES THE TROUBLE
}


Note they define
 
               var browser_type=navigator.appName;



I'm not sure whether this is a valid bug or an Evangelism issue.
In NN4.7, this code seems to work. But in Mozilla, things go wrong:

The new value in the "Category" selectbox is PRESERVED
(in my case,  "Questions About Plus Service").

But the new values for the "Subject" selectbox get RELOADED
to their original values...


Reassigning to History:Session for further triage; cc'ing jkeiser -
Assignee: rogerl → radha
Component: JavaScript Engine → History: Session
QA Contact: pschwartau → claudius
Status: UNCONFIRMED → NEW
Ever confirmed: true
SUMMARY

1. The parent selectbox is "Category"; the user makes a choice here
2. The child selectbox is "Subject". The list of options in this list
   is set dynamically from the Category choice via the function updateList()
3. The updateList() function works just fine, but in the Netscape codepath, 
   concludes with history.go(0)
4. In NN4.7, the history.go(0) preserves the contents of both the
   parent and child selectboxes. 
5. In current Mozilla builds, the contents of the parent selectbox
   are preserved, but the dynamic contents of the child selectbox
   are reloaded to the values they had on initial page load -
I would suggest using location.reload() instead of history.go(0) as the behavior
of history.go(0) has changed in NS6.x and mozilla. It would also be good to find
out why a history.go(0) is done in the first place for NS4.7. may be it was done
to work around a bug in NS4.x which is no longer necessary in NS6.x.
I don't really see a session history bug here. Marking this "Won'tFix" until I
get a response for my previous suggestion. 
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Is this bug a dead issue?  It's been marked as WONTFIX for four months now.  
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.