62226 - Cannot send new message (mail doesn't recognize recipient)

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Tracy Walker [:tracy]]

seen on commercial builds:
windows 2000-12-07-06-Mtrunk
linux 2000-12-07-06-Mtrunk
mac 2000-12-07-05-Mtrunk

- compose a new mail message
- enter recipient (note: it won't allow multiple recipients to be entered)
- send message

expected results:   mail is sent

tested results: a warning message pops ups saying no recipients have been 
entered. please...blah blah blah...end result new meassage cannot be sent

also note:  it is possible to send messages and to mutliple recipients by 
replying to a message.

Comment 1

[scottputterman]

reassigning to ducarroz.  cc'ing sspitzer and mscott in case they are around as
well.

Comment 2

[Jon Granrose]

I see this on my NT box with today's build also.  I can send mail if I use my
addressbook, but cannot send mail by entering a new address.

Comment 3

[David :Bienvenu]

Here are some console msgs bringing up the new compose window:

chrome://messenger/content/messengercompose/addressingWidgetOverlay.js line 706:
 reference to undefined property selectElem.data

JavaScript strict warning:
chrome://messenger/content/messengercompose/addressingWidgetOverlay.js line 706:
 reference to undefined property selectElem.data

Comment 4

[Jean-Francois Ducarroz]

Looking at it right now...

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Blake Ross]

We've been looking at this for awhile, and are a little stuck.  Lots of 
checkins that could have regressed this...

Comment 7

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

I have checked in a workaround. 

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

I'm looking at the underlying problem at the moment. I'm going to mark this 
fixed and open a new bug on fixing the underlying problem. 

Comment 8

[Jean-Francois Ducarroz]

A tree pulled with the date 12/07/2000 01:00:00 works fine.

Comment 9

[Jean-Francois Ducarroz]

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

Comment 10

[Tracy Walker [:tracy]]

verified fixed on commercial builds:

windows 2000-12-08-06-Mtrunk
linux 2000-12-08-06-Mtrunk

Comment 11

[Jean-Francois Ducarroz]

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