84633 - drop-down list is empty

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[Wiktor Wodecki]

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

Comment 1

[Wiktor Wodecki]

Attachment: the page where the combobox isn't displayed correctly

Comment 2

[Conor Lennon]

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

Comment 3

[Conor Lennon]

Attachment: testcase

Comment 4

[Wiktor Wodecki]

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

Comment 5

[Chase Tingley]

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.

Comment 6

[Wiktor Wodecki]

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

Comment 7

[selmer (gone)]

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

Comment 8

[Bernard Alleysson]

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

Comment 9

[Kevin McCluskey (gone)]

This is a parser issue. Reassigning.

Comment 10

[Chase Tingley]

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

Comment 11

[harishd]

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.

Comment 12

[Chase Tingley]

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

Comment 13

[Chase Tingley]

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.

Comment 14

[Bernard Alleysson]

"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 

Comment 15

[harishd]

Putting under evangelism radar.

Comment 16

[Bernard Alleysson]

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 ?)

Comment 17

[harishd]

Since it's a regression I will reconsider it!

Comment 18

[Bob Clary [:bc] (inactive)]

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

Comment 19

[Bernard Alleysson]

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 ?

Comment 20

[Bob Clary [:bc] (inactive)]

giving to parser.

Comment 21

[Christopher Blizzard (:blizzard)]

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?

Comment 22

[timeless]

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.

Comment 23

[harishd]

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.

Comment 24

[harishd]

Marking WONTFIX.

Comment 25

[Wiktor Wodecki]

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

Comment 26

[Bernard Alleysson]

"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

Comment 27

[Christopher Blizzard (:blizzard)]

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.

Comment 28

[harishd]

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.

Comment 29

[Heikki Toivonen (remove -bugzilla when emailing directly)]

<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.

Comment 30

[doctor__j]

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

Comment 31

[Chase Tingley]

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

Comment 32

[Chase Tingley]

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

Comment 33

[Bob Clary [:bc] (inactive)]

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.

Comment 34

[Harshal Pradhan]

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