94432 - HTMLSelectElement.remove() doesn't work right with OPTGROUPs

Status: VERIFIED FIXED

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

Description

[david]

If I define a SELECT element that contains OPTGROUP elements, then use the
remove() method to delete OPTIONs from the SELECT, the first call to remove()
succesfully removes an OPTION from the visual display, but does not change the
length of the options[] array.  If I then try to delete an option from the same
position, nothing happens.

See the attached testcase to see what I'm talking about.  If you take the
OPTGROUP tags out, the code works as expected. 

This is with Mozilla 0.9.3

Comment 1

[david]

Attachment: testcase

Comment 2

[Keyser Sose]

Confirmed
Platform: PC
OS: Windows 98
Mozilla Build: 2001081403

Good testcase btw.

Comment 3

[Sivakiran Tummala]

looks like the problem is with the index...if the index is greater than one it
is not able to remove....
if the index == 0 then it works the first time

Comment 4

[John Keiser (jkeiser)]

As of 2001092113 Linux, this does not even remove the first (normal) option. 
However, the bug 34297 patch fixes removing the optgroup at least.  Setting
dependency.

Comment 5

[John Keiser (jkeiser)]

Fixed with bug 34297 landing.

Comment 6

[Sivakiran Tummala]

verified 2001-09-09 

Comment 7

[Sivakiran Tummala]

Reopening bug failed with the testcase provided by reporter. win2k build
2001-11-26. regression from 6.2

Comment 8

[John Keiser (jkeiser)]

WFM on 2000-11-27 Linux.  Are you sure you're not expecting it to delete the 0th
option (the visible one)?  The wording there is sort of deceptive, it deletes
option #1 (the second option, in the optgroup).

If not, please describe your symptoms.

Comment 9

[Sivakiran Tummala]

Did not work with 11/26 build on linux . The symptoms are the same as the
reporter described, the first call to remove() removes the first option
(visually) but length does not change. Second call to remove() does nothing, length
being the same through out.

Comment 10

[Johnny Stenback (:jst)]

WFM too.

Comment 11

[Sivakiran Tummala]

The testcase failed on 6.2.1 build

Comment 12

[John Keiser (jkeiser)]

And you are sure this was working in 6.2?  I know *I* didn't make the fix there.
 This bug was neither nominated nor targeted to 6.2, and as you can see, it was
not working as of 0.9.3.  This is not a trivial patch to dump into the tree,
either; it is a *huge* set of code that was part of the bug 34297 patch. 
0.6.2.1 is *not* based on 0.9.6, which is where this bug finally got fixed.

So please either nominate for 0.6.2.1 or re-close, if you could.  Be aware that
even if you nominate, there is a very very small chance that anyone will have
the time or inclination to rework this in 0.6.2.1, especially since it's fixed
on trunk.  It is not a trivial bug to fix.

Gentle reminder, if you are testing under non-trunk builds (like 6.2) you should
specify that when talking about it so we can avoid unnecessary closing/reopening
like we just had.

Comment 13

[Sivakiran Tummala]

this failed on branch build, it is a regression from 2001-11-09 not from 6.2

Comment 14

[John Keiser (jkeiser)]

I'm rather surprised that it was working on 2001-11-09 branch either (branch
being ->6.2.1).  Are you certain you tested it on 2001-11-09 branch (->6.2.1)
rather than trunk (->0.9.6)?  Your comments at that date give no indication, so
maybe you were testing with trunk, which *was* fixed ...

As far as I know nobody else gave this any attention (I am CC'd on most other
relevant optgroup bugs as well).  And no one checked it into the branch because
it was waaaay to big and wouldn't apply properly anyhow.  Failure in any 6.2.1
branch build is expected.  Success would be surprising.

Comment 15

[Sivakiran Tummala]

my bad, agree with you john

Comment 16

[John Keiser (jkeiser)]

No prolbem at all, thanks!

Comment 17

[Sivakiran Tummala]

verified fixed