Closed Bug 32702 Opened 24 years ago Closed 24 years ago

1st addressing field not working in New Msg/Plain compose

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: esther, Assigned: pollmann)

Details

(Whiteboard: [PDT+] (TRUNK ONLY) fix in hand) 

Using trunk builds 2000-03-21-09M15 on win and linux and -08 on Mac the 1st 
addressing field doesn't hold what is typed and if you send with just one 
recipient the send fails.  To work around you have to enter a name in the 2nd 
field.  This is for plain text compose only.

1. Launch Seamonkey
2. Open Mail
3. Change your formatting to plain text compose (in Account Setup)
4. Click New Msg 
5. Type in the 1st field and click <enter> or <tab>.
Result: the text you entered is not there!
Expected: the text to stay in the field

6. Click Send- errror message about no recipient, so the text is really gone 
not just hidden.
Workaround- enter the name in the 2nd addressing field.
JFD - can we fix this soon?
Keywords: dogfood
Target Milestone: ---
I am looking at it right now...
Status: NEW → ASSIGNED
Target Milestone: --- → M15
does it work in HTML? Addressing widget has nothing to do with the format of the 
message!
I can reproduce this bug on both my Mac & Window. Some time, I crash when I type 
someting in the first field and then click in the subject field:
__sbh_free_block(tagHeader * 0x00c51efc, void * 0x0345f530) line 350 + 6 bytes
_realloc_base(void * 0x0345f530, unsigned int 0x00000090) line 101 + 13 bytes
realloc_help(void * 0x0345f550, unsigned int 0x0000006c, int 0x00000001, const 
char * 0x00000000, int 0x00000000, int 0x00000001) line 636 + 16 bytes
_realloc_dbg(void * 0x0345f550, unsigned int 0x0000006c, int 0x00000001, const 
char * 0x00000000, int 0x00000000) line 806 + 27 bytes
realloc(void * 0x0345f550, unsigned int 0x0000006c) line 755 + 19 bytes
JS_realloc(JSContext * 0x03433e90, void * 0x0345f550, unsigned int 0x0000006c) 
line 1032 + 14 bytes
js_AllocSlot(JSContext * 0x03433e90, JSObject * 0x02201cb0, unsigned long * 
0x0012ef10) line 1505 + 20 bytes
js_NewScopeProperty(JSContext * 0x03433e90, JSScope * 0x0345e080, long 
0x023513d0, int (JSContext *, JSObject *, long, long *)* 0x002a1235 
_JS_PropertyStub, int (JSContext *, JSObject *, long, long *)* 0x002a1235 
_JS_PropertyStub, unsigned int 0x00000006) line 477 + 20 bytes
js_DefineProperty(JSContext * 0x03433e90, JSObject * 0x02201cb0, long 
0x023513d0, long 0x00000005, int (JSContext *, JSObject *, long, long *)* 
0x002a1235 _JS_PropertyStub, int (JSContext *, JSObject *, long, long *)* 
0x002a1235 _JS_PropertyStub, unsigned int 0x00000006, JSProperty * * 0x00000000) 
line 1660 + 29 bytes
DefineProperty(JSContext * 0x03433e90, JSObject * 0x02201cb0, const char * 
0x010a4168, long 0x00000005, int (JSContext *, JSObject *, long, long *)* 
0x00000000, int (JSContext *, JSObject *, long, long *)* 0x00000000, unsigned 
int 0x00000006, JSProperty * * 0x00000000) line 1514 + 43 bytes
JS_DefineConstDoubles(JSContext * 0x03433e90, JSObject * 0x02201cb0, 
JSConstDoubleSpec * 0x010a4038) line 1580 + 34 bytes
InitInstallTriggerGlobalClass(JSContext * 0x03433e90, JSObject * 0x02201108, 
void * * 0x0012f038) line 624 + 19 bytes
NS_InitInstallTriggerGlobalClass(nsIScriptContext * 0x03432080, void * * 
0x00000000) line 652 + 17 bytes
nsSoftwareUpdateNameSet::InitializeClasses(nsSoftwareUpdateNameSet * const 
0x022efa70, nsIScriptContext * 0x03432080) line 515 + 11 bytes
nsScriptNameSetRegistry::InitializeClasses(nsScriptNameSetRegistry * const 
0x013b9f80, nsIScriptContext * 0x03432080) line 81 + 16 bytes
nsJSContext::InitializeExternalClasses() line 665 + 27 bytes
nsJSContext::InitClasses(nsJSContext * const 0x03432080) line 708 + 209 bytes
nsJSContext::InitContext(nsJSContext * const 0x03432080, nsIScriptGlobalObject * 
0x034320e0) line 647 + 12 bytes
NS_CreateScriptContext(nsIScriptGlobalObject * 0x034320e0, nsIScriptContext * * 
0x034319d0) line 921
nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x03431930) line 2466 + 
50 bytes
nsDocShell::GetScriptGlobalObject(nsDocShell * const 0x03431958, 
nsIScriptGlobalObject * * 0x0012f214) line 1863 + 19 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x03432bd0, nsIWidget * 
0x03431764, nsIDeviceContext * 0x03432b10, const nsRect & {x=0x00000002 
y=0x00000002 width=0x000001ae height=0x00000012}) line 458 + 56 bytes
nsDocShell::SetupNewViewer(nsDocShell * const 0x03431930, nsIContentViewer * 
0x03432bd0) line 2186 + 63 bytes
nsWebShell::SetupNewViewer(nsWebShell * const 0x03431930, nsIContentViewer * 
0x03432bd0) line 758 + 13 bytes
nsWebShell::SetDocument(nsWebShell * const 0x03431930, nsIDOMDocument * 
0x03431174, nsIDOMElement * 0x03432e60) line 3152 + 27 bytes
nsGfxTextControlFrame::CreateSubDoc(nsRect * 0x00000000 {x=??? y=??? width=??? 
height=???}) line 1075 + 59 bytes
nsGfxTextControlFrame::HandleEvent(nsGfxTextControlFrame * const 0x021b2268, 
nsIPresContext * 0x03034f00, nsGUIEvent * 0x0012fad0, nsEventStatus * 
0x0012f9dc) line 554 + 16 bytes
PresShell::HandleEvent(PresShell * const 0x030340a4, nsIView * 0x03034610, 
nsGUIEvent * 0x0012fad0, nsEventStatus * 0x0012f9dc) line 3025 + 38 bytes
nsView::HandleEvent(nsView * const 0x03034610, nsGUIEvent * 0x0012fad0, unsigned 
int 0x0000001c, nsEventStatus * 0x0012f9dc, int & 0x00000000) line 799
nsViewManager::DispatchEvent(nsViewManager * const 0x030347f0, nsGUIEvent * 
0x0012fad0, nsEventStatus * 0x0012f9dc) line 1729
HandleEvent(nsGUIEvent * 0x0012fad0) line 69
nsWindow::DispatchEvent(nsWindow * const 0x030344e4, nsGUIEvent * 0x0012fad0, 
nsEventStatus & nsEventStatus_eIgnore) line 498 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fad0) line 519
nsWindow::DispatchMouseEvent(unsigned int 0x0000012e, nsPoint * 0x00000000 
{x=??? y=???}) line 3057 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x0000012e, nsPoint * 0x00000000 
{x=??? y=???}) line 3264
nsWindow::ProcessMessage(unsigned int 0x00000201, unsigned int 0x00000001, long 
0x00b70083, long * 0x0012fd98) line 2256 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x00a704ca, unsigned int 0x00000201, unsigned int 
0x00000001, long 0x00b70083) line 676 + 27 bytes
USER32! 77e71820()

I've just check all the addressing widget code and I haven't find any place 
where we could clear the content of the edit field. This is a very wierd bug. I 
am reassign it to ender team for further investigation
Assignee: ducarroz → beppe
Status: ASSIGNED → NEW
Putting on PDT+ to get fix on trunk ASAP please.
Whiteboard: [PDT+] TRUNK ONLY
beth is on sabbatical, I believe.  cc: kathy brade.
reassign to pollmann; cc jfrancis; this may be related to a checking by pollmann 
which he got from jfrancis.  The text is disappearing due to the new calls added.  
Note:  the real problem may have something to do with the cloning of the nodes 
which has a partial stack crawl like this:
  ...
  nsGfxTextControlFrame::RestoreState
  RestoreFrameStateFor
  FrameManager::RestoreFrameState
  ... (6 of these) ...
  PresShell::ContentAppended
  nsXULDocument::ContentAppended
  nsXULElement::AppendChildTo
  nsXULElement::InsertBefore
  nsXULElement::AppendChild
  ...
Assignee: beppe → pollmann
btw, another workaround for this bug is to comment out the line in 
MsgComposeCommands.js for hiding the formatting toolbar (line 210?).  Without 
that line I don't have this problem.

CC'ing Nisheeth because of RestoreFrameState call / cloned node connection. 
I'll see if I can make sense out of this one.
Status: NEW → ASSIGNED
Eric--I didn't see the same code path at all if the formatting toolbar is not 
hidden.  I think your change just uncovered a bug somewhere else...

I don't see this in my tree which was pulled before Ducarroz's address widget
update.  This might be an unhappy coincidence of Ducarroz's changes PLUS
Jfrancis' fix that I checked in that enables clearing text fields PLUS
Nisheeth's checkin to enable restoring frame state for cloned nodes.  I'll keep
looking at this, but I've got to update my tree first to get Ducarroz's changes,
so it may take some time.

I also notice that this is only when the first address field contains an
address, then the second address field is created.

If you enter an address in the first field then hit TAB, the cursor moves to the
subject input, but doesn't create a second address field.  The first address is
not erased in this case.

If you enter an address in the first field, click on the Subject line, the
second address input will be created and the first will be erased.  If you then
re-enter an address on the first line, it works.

Something funky going on when we generate the second address input?  This
doesn't happen when the third, fourth, ... address inputs are created.

>I also notice that this is only when the first address field contains an
>address, then the second address field is created.
Right, we don't need to add a new row if we still have an empty one.

>If you enter an address in the first field then hit TAB, the cursor moves to
>the subject input, but doesn't create a second address field.  The first 
>address is not erased in this case.
Again, it's the right behavior

>If you enter an address in the first field, click on the Subject line, the
>second address input will be created and the first will be erased.  If you then
>re-enter an address on the first line, it works.
We should not create a new recipient row in this case, I'll file a bug for that

A little debugging shows that as soon as the compose window pops up, the frame
state for the first text input is saved.  The state saved is "" because nothing
was entered yet.  The reason this is triggered is a bug.

After the window appears, an address is entered.
A new row is appended, this caues the frame state of the first text input to be
restored ("").

The bug seems to be in nsGenericHTMLElement::GetPrimaryPresState().  This
routine calls GetHistoryState.  It seems to want the existing history state, but
GetHistoryState actually captures state for the frames, then returns it.

I've renamed GetHistoryState to CaptureAndGetHistoryState and created a
GetHistoryState routien.  I've also replaced all calls to GetHistoryState with
CaptureAndGetHistoryState.  I'll do some testing and see if this solves the
problem.

The remaining question is why AppendChild causes the text input to restore it's
state.
This fixes the bug.  I've got to test this out some more, and get a review
(probably from Hyatt, who wrote nsGenericHTMLElement::GetPrimaryPresState() or
Nisheeth)
Whiteboard: [PDT+] TRUNK ONLY → [PDT+] (TRUNK ONLY) fix in hand
The state is restored, what appears to be an extra time, when the second field
is created because of this:

PresShell::ContentAppended{
...
rv = GetPrimaryFrameFor(aContainer, &frame);
if (NS_SUCCEEDED(rv))
  mFrameManager->RestoreFrameState(frame, mHistoryState);
...

We restore the state for the container that the new content is added to, not
just the new content.  I changed this to get the new content and restore just to
that.  This also fixes the bug, independent of the first fix.

Should both of these changes be made?
The second change (in PresShell::ContentAppended) breaks session history.  I'm 
looking into it.
First fix checked in.  I'm going to leave the second change fall to the ground 
now because it isn't needed, and causes problems.

To verify:
 Open the messenger window.
 Choose Mail/News Account Settings from the Edit menu.
 Click on the mail server
 Uncheck the bottom box: Compose messages using html
 Click on Okay to close settings dialog

 Click on New Msg in the messenger window.
 Enter an address on the first line of the new message.
 Click on the blank white space below the first line

A new entry line should be created.  The first line should not be erased.  
Thanks!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
QA Contact: lchiang → laurel
OK using:
2000-03-31-13m15 commercial build linux rh6.0
2000-04-03-09m15 commercial build NT 4.0
2000-04-03-10m15 commercial build mac OS 9.0

Tried in plain text and html compose windows for both mail and news messages.
Tried for both new message and reply windows.
Note:  current mac build has reply window problem and Enter won't add new line.

Will log mac problems separately.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.