62301 - '.value' is broken in mailcompose addressing widget xul:textfields

Status: RESOLVED FIXED

(Core :: XBL, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

From 62226:

Here's what I found when investigating the script object attached to the XUL 
textfield element:

inputField[value] = ""
inputField[input] = "[HTMLInputElement]"
.. etc ..

XUL Textfield's XBL binding in global/resources/content/xulBindings.xml defines 
a property called 'inputField' that is initialized to the anonymous html:input 
field inside the textfield. the property is set by doing:

<property name="inputField" readonly="true">
<![CDATA{
 .. locate the node, assign into local var 'input' ..
 input;
]]>
</property>

the return value of the initialization is what is set. in this case it is set to 
the HTMLInputElement found. However, it seems the /property name/ is being reset 
to the name of this variable!! (as there is no 'input' property defined on 
xul:textfield, how could my for (var i in XULTextFieldElement) walk show a 
property named such?!).. I modified the code in xulBindings.xml to rename the 
local to 'inputField', and sure enough, my walk in the addressing widget code 
showed 

inputField[inputField] = "[HTMLInputElement]"

I'm going to need to investigate this further. This seems like some kind of 
weird XBL bug. I don't know why it isn't affecting other textfields or other 
autocomplete widgets (URLBar in browser works). I checked in a workaround so we 
could open the tree... the workaround is as follows:

replace 

inputElement.value

with

inputElement.input.value

(referring to the value of the anonymous input field).

Comment 1

[Jean-Francois Ducarroz]

The menu list used for recipient type (to, cc, bcc, etc) doesn't work either.
This problem occurs at the same time that bug 62226 appends. Seems to be related
to the same bug!

Comment 2

[scottputterman]

changing the severity since this prevents us from using newsgroups. How is this
one going?

Comment 3

[David Hyatt]

i can't reproduce this.  everything is fine for me on win32 and linux.

Comment 4

[Jean-Francois Ducarroz]

I did a clobber build on Windows today and both textfield and menu list are
still broken in the addresing widget (I've removed the patch Ben did, see bug 62226)

Comment 5

[scottputterman]

I just downloaded Win32 build 2000121204 and it doesn't work in this.  When I
open a message compose window I can't change the "To" field to anything else.
When I'm in a newsgroup and do a reply it puts the newsgroup in "To" instead of
"Newsgroup" and it can't be changed.

Comment 6

[David Hyatt]

the menulist is broken for me, but the textfield works fine.  i guess i'll look 
at the menulist bug in the hopes that they're the same problem.

Comment 7

[Tobias Burnus]

Suggest OS=All

Comment 8

[David Hyatt]

This bug is in the mailcompose JS code.  The problem function is

CompFields2Recipients

It creates a cloned treechildren that is not yet in the document.  It then tries
to put a menulist underneath and set the selectedItem, but the menulist is not
in the document yet, so the selectedItem gets placed on the object.  When the
binding gets installed (properly) after you put the element in the document
(through a replaceChild in the CompFields2Recipients function), then the binding
comes in, but it's too late.  The selectedItem property has been shadowed and
you're now screwed.

There is no bug in XBL here.  I am unconvinced now that my checkin even caused
this.  The same goes for the input field.

Reassigning to ducarroz.

Comment 9

[Jean-Francois Ducarroz]

Wait a minute. This piece of code is the same since 1 1/2 years. How come it
stop suddently working? Do I have an alternative do go around this problem?

Comment 10

[David Hyatt]

It should never have worked.  It has always been wrong to try to access binding
properties/methods on an element prior to its insertion in the document.  I have
no idea how this could ever have worked.
 

Comment 11

[David Hyatt]

Ok, this bears more investigating.  cloneNode is supposed to set the document
but isn't for some reason.  Taking this back.

God, this bug sucks.

Comment 12

[David Hyatt]

Hot damn.  I found it, and it wasn't my bug.  Hallelujah.

Ok, so the bug was in the XULElement cloneNode method.  When cloning a
lightweight node that is brutally shared, the document was set and bindings
could be used immediately.  When cloning a heavyweight, however, the document
was *not* set.

My change to the tree set an attribute on the outermost treechildren that caused
it to become a heavyweight node rather than a lightweight.  This exposed the
latent lurking bug in the content model and caused the bindings not to be
installed until much later.

Wow, was this nasty.  Sorry for blaming the JS code.