Closed Bug 62226 Opened 24 years ago Closed 24 years ago

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

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tracy, Assigned: bugzilla)

References

Details

(Keywords: smoketest)

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.
Keywords: smoketest
reassigning to ducarroz.  cc'ing sspitzer and mscott in case they are around as
well.
Assignee: putterman → ducarroz
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.
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
Looking at it right now...
Status: NEW → ASSIGNED
*** Bug 62279 has been marked as a duplicate of this bug. ***
We've been looking at this for awhile, and are a little stuck.  Lots of 
checkins that could have regressed this...
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. 
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
A tree pulled with the date 12/07/2000 01:00:00 works fine.
*** Bug 62339 has been marked as a duplicate of this bug. ***
verified fixed on commercial builds:

windows 2000-12-08-06-Mtrunk
linux 2000-12-08-06-Mtrunk
Status: RESOLVED → VERIFIED
*** Bug 62508 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.