Hello, I just installed the 0.9.1 version (binary) on my linux system, and now comboboxes aren't displayed anymore on a webpage (not on all webpages). I attached the page in question, in case somebody might want wonder :-) The last version I used was 0.8, so I can't say if this bug was present earlier or not to 0.9.1

The <option /> doesn't work. <option> does work. Marking as New. I have a better testcase, so'll attach it.

hmm, the <option /> is for internet explorer since, normal xml would be <option/>. But <option /> is standard compliant, too.

Downgrading to major. doing <option>foo or <option>foo</option> both work -- <option /> ususally indicates "this tag has no children", or such was my understanding of xhtml. Does IE really support this? this may be one for Evangelism.

"support" is kind of wrong *g*, it understands it. if you write <option/> it wont work, but it ignores it if you write <option />

This is not a stopper for 091 -> 092. Please evaluate whether 092 is even correct.

bug 85002 and 84939 are all the same If it was working in 0.8 then it is a regression -> add regression keyword ? from bug 85002 it is working in NS 4.7x -> add 4xp keyword ? from regression and 4xp I think that it should be corrected and not evangelized

This is a parser issue. Reassigning.

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

As tingley pointed out <option/> implies an empty option. That is, mozilla exhibits the correct behavior. Bernard, are you absolutely certain that this worked in 0.8 milestone? Marking WONTFIX.

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

Reporter was the one who originally reported that it worked in 0.9, I think. Wiktor, is this true? FWIW, I seem to remember digging up a 4.x version and verifying that the bogus syntax was accepted by it, as Bernard said. If we're marking WONTFIX I suggest putting it under evangelism to make future bug searches easier.

"Bernard, are you absolutely certain that this worked in 0.8 milestone? " I haven't tried myself, it's just what Wiktor says I have an archive of Mozilla releases (with 0.8) I'll try it today

Putting under evangelism radar.

ok I tried with 0.8 and 0.8.1 0.8 is OK (passes both test cases) 0.8.1 is broken I also tried Netscape 4.77 and both test cases work This is a pretty serious bug about empty (or rather blank) combobox content Please reconsider (why not add regression and 4xp keywords ?)

Since it's a regression I will reconsider it!

Since there is no site to be evangelized, will you assign this bug to the appropriate component please?

I'd like to but I'm not a empowered enough :-) maybe change Linux to OS/All since it's been reported with Linux & Windows ?

giving to parser.

So what's up with this? I've seen this on a lot of sites and people keep reporting it to me. The most recent comment was that you can't buy computers off of dell's web site because of it. harishd do you have an update?

oh please, oh please wontfix this again or mark it invalid. reporter: you filed a bug, and we gave you the correct answer: <option/>foo means <option></option>foo which means something very different from <option>foo</option> which is what you actually wanted to say. The fact that this works in old browsers is based on their ignorance of xml. You now know better and can easily fix your page. <option>foo<option>foo would also work and is what a non xml aware browser is reading when it sees <option />foo<option />foo.

timeless: I totally agree with you. Though this is a regression what we do now is more correct, IMO, than before. I vote for wontfix.

Marking WONTFIX.

I cannot agree with you since <option /> is valid xml and therefore should be supported. Reopend again. Read the specs.

"The fact that this works in old browsers is based on their ignorance of xml." I just want to say that's it works with IE5 and 6 and it's the browser I use to go to such sites

Even though there's discussion on whether or not it looks right the fact is that there are a lot of sites that use it. We should support it for practical reasons.

Wiktor: I agree that <option /> is a valid xml. But the argument here is whether <option/>foo should be treated as <option>foo</option> or as <option></option>foo. And I think the latter is more correct than the former. CCing heikki for more comments.

<option/> is incorrect HTML, but we do work around a lot of bad HTML. However, that markup happens to have special meaning in XML, and I am pretty sure nobody used that markup until XML came along. The space just before the slash has been recognized as a trick to use while migrating to XHTML because many older browsers kinda work with that. The trick was only meant for empty elements, though, like img and br. The idea was that you could mark your page in XHTML, but serve it as text/html while there was still a lot of old browsers around. At some point you could simply switch the mime type to an XML type and your page would work without any modifications. As such its use for non-empty elements is totally inappropriate. If we supported this incorrect markup, your pages would stop working when you switched to XHTML. It is better to teach developers to use the correct markup now, rather than let this incorrect markup spread and cause lots of grief in the future when people migrate to XHTML. Closing this as wontfix. Evangelism please take care of sites that incorrectly use the empty element trick in HTML.

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

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

This bug has now accumulated two dups on rcommerce.us.dell.com. Is Dell actually on the evangelism radar for this issue?

Dell does not have an evangelism bug filed on it for any reason. Please reopen one of the dupes and assign it to Evangelism. Thanks.

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