The Javascript syntax to create a new menu item is myoption = new Option("description","value"); This results in a Javascript Error "Option is not defined" in the 2/19/99 build. Wasn't sure if this was properly a DOM bug, but I didn't see a JS specific option

Yup. It's on my list.

Moving to Mozilla product to assign to Javascript component.

Moving to M6 for now.

OK, I've got my part of it working. The Option constructor works and the resultant Option element can be added to a Select element's option list. This modifies the content tree under the Select element. Unfortunately, this doesn't actually modify the Select widget. Eric Pollmann has an existing bug related to the last point. Eric, I'm reassigning this bug to you. Please don't DUP it with your existing bug. When you close the existing bug, try out the attached test case and close this one as well.

I've got my part working now too. Well, there is still a glitch where the "currently selected" information is lost when an option is removed via the DOM methods (not using Select's Remove method), or when an option is replaced, as in this demo. Vidur, the frames and widget code will handle removal correctly (not destroy all the options or loose selection information) if it is handed an index. For example, if you use the <SELECT>'s Remove method, things are handled correctly. Can you come up with a way to divine the index? Pusing that part of the bug off to M9 or so...

Mostly working, but still a glitch. I have a couple apps that change the items in one menu when an item is selected from another. This works, but it doesn't actually updates until I first click and change the first menu, and *then click and not change the same menu*. I have to click twice on it before it will reflect the update. These apps are internal, but I could make one available on a public net if it is necessary.

Yep, that is another, unrelated problem you are seeing, bug 3322. If you have a good test case for that bug, feel free to add it to the bug report for 3322, thanks!

The glitch you noticed should be fixed now for Windows and GTK - see bug 3322.

Yes, the symptoms that I saw attributed to bug 3322 have been fixed for my test cases...whoo whoo ;-)

*** Bug 6928 has been marked as a duplicate of this bug. ***

After careful consideration, I've decided that I probably won't get this bug in for M12. Currently I have nearly 50 bugs scheduled for M13, so there is a possibility that this bug may need to be moved out farther still.

This is going to take a lot of work and has little payoff. Pushing off to M17...

Rescheduling - bugs of this priority won't make it until around M19.

Rescheduling

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Mass update of qa contact

QA contact Update

Updating QA contact to Shivakiran Tummala.

As far as I can tell, everything is working fine now. I can do everything expected in the test case. I tried creating a testcase that used the DOM removeChild() method and that appears to work too. Can someone explain more clearly what is supposed to go wrong? I'll give it a week and close this as WORKSFORME if there are no objections.

Bulk reassigning form bugs to Alex

jkeiser's testcase works for me as well on linux

worksforme 2001-11-09-09.

I'm certain Alex won't have any problem if we close this one. Woohoo, 4-digit bug closed!

You're damn right John. I'm really glad when bugs get resolved :-)

verified fixed