When an <option> is generated with javascript document.write it is impossible to select it. Also all options following it are impossible to select even if they are written in normal html. To reproduce, try the drop down on the bottom of the url in this bug, or in the upcoming testcase. This is 20010917 on WinMe.

Confirmed on latest CVS. Confirmed fixed in the first bug 34297 patch, however (out soon). Setting dependency so I'll remember to update this bug, though if someone wants to fix this first, go ahead.

I can confirm this on MacOS 9.1 and build 2001100108. It was not there in the 0.9.4 release. This is a "major" problem to for instance internet banking.

I don't think it is legal to have script right in the middle of a select. jst, does that sound right to you?

It happens all over the place, and I can see lots of people doing something like <SELECT><SCRIPT>for(i=0;i<numOptions;i++) { document.write("...") }</SCRIPT></SELECT>. According to the spec, <SCRIPT>document.write("")</SCRIPT> is supposed to make whatever is in the document.write() *replace* the SCRIPT, so it shouldn't be a problem. (The fact that the SCRIPT currently stays around in the content model is inconvenient at best.)

That would sure make the code simpler :) If you guys decide to invalidate it, just assign it to me instead. Whether it's right or not, it's fixed in the form submit / select patch.

I'll have to try to remember exactly what I was thinking about. Anyway, if this is fixed in the select patch, than all the better.

Only the <option>s before the document.write option is visible in DOM. Funny thing is that the select displays a blank selection if any of the "unselectable" options are clicked.

ok, the <option>s are accessible via childNodes but not options. Attaching a testcase to show.

The JavaScript looks fine in my patch as well. That's a very funky testcase, I like how the unselectable options show up with white on black anyway :)

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

Fixed with bug 34297 landing.

The javascript generated <option> works fine on the branch build 2001-10-22-18-0.9.4 I am able to make the selection on this build. ** fixed on branch build ** But this is broken on the trunk build. Tested on 2001-11-01-03-trunk win2000. see testcase http://bugzilla.mozilla.org/showattachment.cgi?attach_id=56623 ** not fixed on trunk build ** Need to move the patch on trunk build as well. Reopening the bug.

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

this should have been a All All bug at any rate with build 2001110503 win32 this wfm I thinking this is fixed by patch in bug 34297

build 2001110503 is again the branch build. As mentioned in my previous comment, The issue is fixed on Branch. The fixed patch needs to be moved into trunk build, as well. This bug is still an issue on the trunk build.

Are you talking about trunk like Netscape 6? If so, someone is going to have to look into this problem freshly (from pre-34297 POV), because I'm fairly certain you don't want the bug 34297 can-of-worms changes lumped into the trunk. To help speed things along, here is a diagnosis I made (part of a comment) in bug 100511: ------- Additional Comments From John Keiser 2001-09-19 16:39 ------- ... The source of the problem is probably jesup's select insertion performance improvement (bug 97345), but I can't be sure because I redid that in my patch. The problem for me (which was probably also a problem for him) was the fact that AppendChildTo() is called twice, once for the AppendChildTo(<SCRIPT>) and then immediately afterwards (recursively) to the created <OPTION>. The catch is, when the call is made to AppendChildTo(<OPTION>), the <SCRIPT> element is already in the tree (in front of the option)! This means that the tree is no longer flat, but since the AppendChildTo(<SCRIPT>) call that triggered it hasn't finished, the select is not yet aware of this (it checks *after* calling the parent AppendChildTo()). ...

Hmm, this works fine in both Netscape 6.2 and todays nightly build. Fixed?

agreed fixed on 2001-11-06-03 trunk build as well. It was broken on 2001-11-01-03 trunk build. marking fixed.

verified