57217 - userdefined tags not autoclosing properly

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect, P3)

Description

[rickg]

Given this sequence:
<foo>
   <bar>
   <bar>
</foo>

We'd expect the </foo> to close the inner bar's and the <foo>. It doesn't. I 
can't imagine why we never caught this case before. Palm.com shows this error, 
and it appears as dataloss.

Comment 1

[rickg]

harish: I'm reassigning this to you. I doubt it will be a candidate for N6. The 
most important aspect of this is that </foo> closes <foo> and all the 
intervening tags. Today, it only closes the top userdefined tag, which is 
clearly wrong. Perhaps we need to target the tag by type *and* userdefined name.

Comment 2

[rickg]

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

Comment 3

[harishd]

Not a ship stopper. FUTURE candidate.

Comment 4

[harishd]

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

Comment 5

[bsharma]

updated qa contact.

Comment 6

[rubydoo123]

adding WRMB, topembed and marek and chofmann

Comment 7

[chris hofmann]

beppe, can you add the additional sites in the WRMB effor that seem to
turn this problem up?

Comment 8

[chris hofmann]

I'm not sure the palm site shows the dataloss problem on 0.9.2 builds or later.
does anyone else see the problem?

Comment 9

[harishd]

I don't!

Comment 10

[Marek Z. Jeziorek]

I do not see the dataloss either, but they could have changed the site. 1. Do we
still have a general problem that rickg described? 2. Are there any other top
sites that exhibit this problem? If the answer to both questions is YES then we
still should give it a high priority and set TM appropriately. If the answer to
both is NO then we should resolve it. If the answer to 2 is NO then we should
remove topembed from the bug.

Comment 11

[harishd]

It's been ~8 months since the bug got opened and we haven't seen any duplicate
whatsoever. Could that mean that there are not many sites that exhibit this
problem? May be...may be not. The bottom line is that we don't have numbers to
pursue this problem further. IMO, it ain't worth a risk to fix an "unknown" problem.

Comment 12

[chris hofmann]

agree.   we just need to find out which possible war room bugs/sites 
are assoicated with this possible problem...  beppe, can you track that
down and update this bug.  thx

[e-mail] keywords   topembed 2001-08-15 10:39:05 
[e-mail] short_desc userdefined tags not autoclosing properly WRMB:
userdefined tags not autoclosing properly 2001-08-15 10:39:05

Comment 13

[harishd]

Ccing Beth.

Is this bug still an issue?

Comment 14

[Dave Barrowman]

I asked Bob Clary about this yesterday and he says that he doesn't know of any
sites (esp. War Room sites) which currently exhibit this bug.  However, he is
concerned that some tools do generate user defined tags and they are not uncommon:

> User defined tags are fairly common. I think GoLive uses them as well as some
other tools.... 
> perhaps Cold Fusion.  IE also supports the creation of user defined tags.
Unless we start finding War Room sites with this bug, it shouldn't be topembed.

Comment 15

[rubydoo123]

this will become more of an issue as web sites move toward XML and XHTML, as for 
current sites with this issue, no I have not seen any reports.

Comment 16

[harishd]

So, should be remove the topembed keyword?

Setting milestone to 0.9.4 for now.

Comment 17

[Marek Z. Jeziorek]

removing topembed and also WRMB (please put WRMB if necessary for some other
reasons). Setting TFV back to Future.

Comment 18

[harishd]

Beppe: There is no such thing as autoclosure in XML and XHTML. That is, every
tag should have a matching end tag. Therefore,

<foo>
 <bar>
 <bar>
</foo> 

would be illegal.

Comment 19

[Marek Z. Jeziorek]

While the structure above is incorrect, we should have a reasonable error
handling and try to behave in "do what I mean and not what I say" manner, if
possible.

Comment 20

[Waheed Islam]

Attachment: example to autoclosing tag bug.

Comment 21

[Waheed Islam]

I have attached a file showing autoclosing not functioning.
However, this bug existed from and before builds 200100830,
but on the recent 20010904, it seems to be working fine!

Comment 22

[Waheed Islam]

sorry, error above :: 200100830 should be 20010830.

right, i have found a url which demostrates this problem pretty well...
http://www.checkyhat.org

ie displays the site correctly, even though the layout is wrong under netscape 4,
the font sizes are displayed correctly, however notice under mozilla...

since the font tag has not been closed, the layout suffers.

-->
<div id="banner"><FONT FACE="ARIAL" SIZE="10">CHECKYHAT.ORG
<img src="1.jpg">
<img src="2.jpg">
<img src="3.jpg">
<img src="4.jpg">
<img src="5.jpg">
<img src="6.jpg">
<img src="7.jpg">
<img src="8.jpg">
<img src="9.jpg">
</div>

closing the font tag, fixes the large font-size error.

Comment 23

[Waheed Islam]

right sorry, my comments above are not for userdefined tags, but rather
generalised to autoclosing function not working with normal tags.

Comment 24

[rubydoo123]

removing myself from the cc list

Comment 25

[Christopher Hoess (gone)]

To add to comment #18, since so-called "userdefined" tags aren't specified in
the standard, we don't know what their minimization properties are or how they
fit into the content model, so it's simply not possible to reliably do this. I
suggest this bug be INVALID or WONTFIX.