117247 - select does not restore options when options are changed

Status: RESOLVED DUPLICATE of bug 38486

(Core :: Layout: Form Controls, defect)

Description

[Robert Praetorius]

after you select an item from a drop-down list in a form, using either
MB1 or <Enter>, there's a pause and then the browser (or JS engine?)
selects the previous item on the list.

Using Mozilla 0.9.7 2001122106 on NT 4.0 SP6a
Also broken in Netscape 6.2, works in Netscape 4.78

Note that the URL in question is members only.  I've made a much
smaller (but still probably larger than it needs to be) test case that
reproduces the problem and will attach it.

Also, if it ends up being evangelism, it looks like McAfee (or whoever
did the page for them) got the code from 

        http://javascript.internet.com/forms/country.html#source

(and then modified it slightly), so those people would need to be beat
on, too, no, I mean, errr, encouraged to convert to a more portable,
standard solution.

I see there are a boatload of form/select/JavaScript bugs.  I didn't
find one that exactly matched my symptoms after looking at quite a
few, but this may easily be a duplicate.  I'll leave that to somebody
who knows the territory better.

Comment 1

[Robert Praetorius]

Attachment: select from the first drop-down box and watch it jump up one

Comment 2

[Asa Dotzler [:asa]]

-HTML Form Controls (maybe it belongs in DOM?). Confirmed with 122802 mozilla
windows build (win2K).  I tested mac and linux nightly builds and they do not
have this problem. 

Thanks for the very thorough bug report and reduced test case, Robert. 

Comment 3

[Asa Dotzler [:asa]]

mgalli, do you recognize this? if the copied code is widespread and it turns out
to not be our bug then you guys might want to investigate the original code. 

Comment 4

[rods (gone)]

john, can you take a look?

Comment 5

[John Keiser (jkeiser)]

This works for me, I am 98.6% certain it was fixed with bug 112241.  Reopen if
you are still seeing this.

Comment 6

[Robert Praetorius]

(this is the original reporter)

I'm still seeing this in 0.9.9 (2002031104)

Comment 7

[John Keiser (jkeiser)]

Please try with a nightly.  I know of another testcase that was just like this
that was very recently fixed.  I'll leave this open in the meantime.  Thanks :)
 It still works for me.

Comment 8

[Robert Praetorius]

(this is the original reporter)

still breaks for me with 2002040803.

This is kinda out there, but do you think having Large Fonts selected for the
system fonts could be related?  I see it blamed for many kinds of glitchiness.

You might also double check with [e-mail], who was also apparently able
to reproduce it.

Comment 9

[Marc Boullet]

Attachment: test case which will show the bug on every OS

Comment 10

[Marc Boullet]

While trying to dupe bug #136885, I found this one.

The cause of this bug is a window.history.go(0) which was conditionned
in the original page by browser==Netscape and OS==Winxx.

In the testcase I attached, I condition the history.go(0) by unchecking the
checkbox (default).

history.go(0) is similar to a reload button. In NS4, since there is no reflow after
the page is loaded, it is used to create an "artificial" reflow when a combobox
has been modified (see Netscape Javascript 1.3 reference manual).
More....

Comment 11

[Marc Boullet]

If you don't reload the page, the testcase works perfectly with Mozilla.

Mozilla should restore the combo box in the same state as it was before hitting
reload or a script makes a history.go(0) (at least for NS4 compatibility).

That's what it does when you don't change the structure of the combo box (
remember the selected Index, the check status of checkbox, the content of text
box, etc).

Changing the summary

Comment 12

[Robert Praetorius]

(this is the original reporter)

this problem is still here in 1.0RC3

I suppose it's importance hinges on how commonly used this script is.
Unfortunately, an attempt to search for it (searching for africaArray
and middleeastArray) using several different engines (google, altavista, hotbot,
lycos) seemed to turn up mostly pages where the script was in the text of
the page, not contained in <script ...> </script> (is everybody filtering
for this kinda stuff now?)

Anybody got any ideas for getting a realistic tally on this?

Comment 13

[John Keiser (jkeiser)]

I see what you want.  This is memory-intensive and not worth the effort.  What
we *can* do is provide to developers a mechanism to let them know when the first
select is changed, so that they can then change the second select.  In Mozilla,
actually, if you just change this testcase to call
populateCountry(document.globe,document.globe.region.options[document.globe.region.selectedIndex].value)
 in a script immediately after the <select> (or do it onload) then everything
will look just fine.

http://mozilla.freezope.org/docnotes/FormBugsFAQ#save_restore_everything

*** This bug has been marked as a duplicate of 38486 ***

Comment 14

[Robert Praetorius]

This no longer happens to me with Phoenix 0.5 or Mozilla 1.3 alpha
(Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5,
 Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212)

Which makes me wonder if resolved duplicate is the correct resolution. . .

Either way, somebody fixed something - the first attachment no longer
exhibits the jump-up-one behavior.

Comment 15

[John Keiser (jkeiser)]

Yeah, sorry--enough major pages came up that we fixed it (we found a way to fix
it that wasn't so memory-intensive).