Closed Bug 12477 Opened 21 years ago Closed 21 years ago

template usage in html:select gives extra blank option

Categories

(Core :: XUL, defect, P3, blocker)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: hangas, Assigned: rods)

Details

Attachments

(1 file)

When using a template to generate options in a select from rdf, an extra blank
option appears at the top of the list.  It appears to be the option from inside
of the template node.
Chris Waterson wrote:
>  Is this really a blocker?

We probably need to fix this by beta
I think I know why the blank line is there though.
the RDF template code inserts a child called <template> in front of all the
template-generated children.

I think the combo box is the first widget that isn't smart enough to ignore
unrecognized nodes. the <select> widget is supposed to only use <option>
widgets.

CC'ing rod, because he can probably fix the behavior quicker than rjc/waterson
can change the behavior of templates.
Chris Waterson wrote:
>  Is this really a blocker?

We probably need to fix this by beta
I think I know why the blank line is there though.
the RDF template code inserts a child called <template> in front of all the
template-generated children.

I think the combo box is the first widget that isn't smart enough to ignore
unrecognized nodes. the <select> widget is supposed to only use <option>
widgets.

CC'ing rod, because he can probably fix the behavior quicker than rjc/waterson
can change the behavior of templates.
oops. sorry 'bout the double-post
Status: NEW → ASSIGNED
Target Milestone: M11
Assignee: waterson → rods
Status: ASSIGNED → NEW
rods: can we hack combo boxes to ignore an HTML:SELECT that is contained beneath
a "XUL:TEMPLATE" tag? Paul: could you create a really simple test case for rods?
Chris, I am not sure I understand your request: "ignore an HTML:SELECT that is
contained beneath a "XUL:TEMPLATE" tag". Mostly because I don't know how
templates work in terms of the content sink and nsCSSFrameConstructor. I assume
there are frames getting created for the XUL:TEMPLATE and this is causing a
select to be created? Also, I just checked in a temporary fix this morning
that was crashing the launch of mail-news, where a select had a dropdown that
was completely empty and this should never happen (long story/explanation).
Added waterson to cc list
rods: There is such a SELECT at the top of the New Card dialog from the Address

Book.  The DOM contains a <template> node under the <SELECT> node before the

"real" <OPTION> nodes.  Inside this <template> node there is an <OPTION> node

that is mistakenly used as a "real" <OPTION> and displayed as a blank line.  What

waterson meant to say was to ignore this <OPTION> node inside the <template> that

appears in the DOM.



If you can tell me where we crash in mailnews I can try to get that fixed.
Thnaks for the explanation. A couple of things. The crash isn't quite a mailnews
issue, I think it is because of this whole template thing and some how this
template gets in there and then the frame doesn't display so the dropdown is
smaller than the scrollbars and we get a crash in the view system. My temporary
fix makes sure that the drop down is always bigger than the (native atleast)
scrollbars.

When a select (frame) gets created it ends up calling "ProcessChildren" in the
nsCSSFrameConstructor and that processing is all automatic and very generic. It
just walks down the content hierarchy lookin for childrent and putting them into
the select. I'll take a look at the "SetChildList" method, maybe it can verify
that all the child frames coming have as there content either an option or an
optgroup. But it doesn't really seem like the select should to worry about this.
This whole template thing seems to be putting a wrench in the processing and
should be fixing this. Someone did mention earlier that maybe I could fix this
for now and it should be fixed in RDF later.

I could see what this "temporary" fix takes and then maybe make this an RDF bug
and hand it off to waterson? What do you think?
I like the temporary fix, although I am not sure it will be temporary unless we
choose to not put <template> nodes in the DOM.  So please do this fix and we will
find out what waterson wants to do next.
Hmm, I can put together a simpler test case than address book. How about
this:

<html>
<select>
<template><option>foo</option></template>
<option>bar</option>
<option>baz</option>
</select>
</html>

The idea is that a <TEMPLATE> is meta information tells you how to build
sub-content for the node _above_ it. I think we have rules somewhere that say
"template { display: none; }" so that anything inside the TEMPLATE won't show
up.

That should work, shouldn't it?
Maybe it should work, but xul.css already has this display:none style for
templates and it is still showing up.
I can load this file in the viewer and see the problem.
I think a simple slution would be to add this to xul.css:

template option {
  display: none;
}

Thus making all option elements inside the template be a display none, but this
doesn't work for some reason. Any ideas? But even if this works my guess is
that having templates be frames and a content node inside the select will
probably screw up the entire selection mechanism.

The real problem is that selects are html and they don't know about templates,
they don't handle templates. They assume everything in them is either an
optgroup or option.
Well, if that's the case I vote we just punt on this bug for now. At some point
after M13, we're going to unify the XUL and HTML/XML content models, at which
point maybe we can make HTML smart enough to ignore content nodes that aren't
<option> or <optgroup> tags.
I would rather that we fix html now.  Otherwise I will have to go in and hack up
a bunch of JS to handle the choice of a blank option; every place that we use
templates inside of a select.  That would be a little ugly, but more importantly
it may take me as long to hack around than it would take to fix.  Any chance we
can get this in before PR1?
It would be helpful to understand why this doesn't work:
template option {
  display: none;
}
Any ideas?
Because then maybe all I have to do is work around the selection problem.
I just don't think this one is going to get fixed for beta. You should escalate
it or start changing JavaScript.
I MIGHT have a workaround.
Stay tuned.
same widget time
same widget channel.
This problem does not happen with gfx select.  Marking as fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Sorry for spam, re-assigning phillip's QA contact XPToolkit/XPWidget bugs to
claudius due to restructure
Status: RESOLVED → VERIFIED
based on hangas' comment that this does not apply to gfe-select I am
marking this puppy VERIFIED
You need to log in before you can comment on or make changes to this bug.