Closed Bug 26618 Opened 25 years ago Closed 25 years ago

infinite reflow in addressing widget with more than one recipient

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: laurel, Assigned: hyatt)

References

Details

(Keywords: crash, platform-parity, Whiteboard: [PDT+] UNKNOWN)

Using 2000-02-04-10m14 commercial build on Mac OS 9.0 Maybe a side effect of bug #26344, or fix of bug #25103 When you Reply-All to a message which has several addressees, the compose window will open but application is then frozen. Reply and new message do not exhibit this behavior, nor does reply-all if original message has only a couple addressees. 1. Open POP or IMAP account. Select a message in a mail folder having several addressees -- 3 or more. 2. Click Reply-All. Compose message appears with partial address header list. 3. Try to click in or close the compose window. Can't. Application is frozen. Result: application hangs upon opening reply-all message window having more than a couple addressees. Note: NT 4.0 and Linux builds don't have this problem, however they do not show all addressee headers until you click in the address block.
Severity: normal → critical
QA Contact: lchiang → laurel
Keywords: crash, pp
The comments in Note: about recipients not showing is covered as bug #24950.
Status: NEW → ASSIGNED
Target Milestone: M14
Happens on Linux now as well, see bug 26344.
I'm going to add beta1 in the keyword section, this is really bad and a PDT+ bug (24519) can't be verified until this one is fixed.
Keywords: beta1
Note, this not only happens on Reply to All, it happens in a New Message window when trying to add a 3rd recipient. This is bad, I'm not sure if there is a separate bug for the New Msg window, if so I'll note that in this bug. If not this should be tested too when fixed.
I found the New Msg bug, it's 27091.
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
When we hang, we are in a reflow dead loop (at least on the Mac).
*** Bug 27091 has been marked as a duplicate of this bug. ***
I will mark bug 27269 as a dup of this one (I do this way because this bug is already tagged as PDT+). As bug 27269 is assigned to David Hyatt, I reassign this bug to him
Assignee: ducarroz → hyatt
Severity: critical → blocker
Status: ASSIGNED → NEW
OS: Mac System 9.0 → All
Hardware: Macintosh → All
Summary: Reply all to message with 3 addressees will hang app → infinite reflow in addressing widget with more than one recipient
*** Bug 27269 has been marked as a duplicate of this bug. ***
*** Bug 26344 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] At risk.
To note: Deviating from the original description, this bug occurs on Linux and Mac as per bug 26344 marked a dup of this one.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] At risk. → [PDT+]
*** Bug 27565 has been marked as a duplicate of this bug. ***
*** Bug 27560 has been marked as a duplicate of this bug. ***
I still have the problem on My Mac with a debug build from this morning. Just enter two addresses and then click in the subject line.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 25103
I'm still seeing this problem in 2000-02-14-09m14 mozilla build linux rh6.0 with reply-all.
Blocks: 27560
Hmmmm, let me just go to my trusty Mac box... No wait, I don't have a Mac box. Ok, let me go to my trusty Linux box... Wait, I don't have a Linux box either. This is too hard. I'm going shopping.
Status: REOPENED → ASSIGNED
Maybe Alecf can help you. Alec?
Or I could go shopping for mac/linux boxes. ;)
*** Bug 27751 has been marked as a duplicate of this bug. ***
I have no problem reproducing this on NT. Not that I'm trying to spoil your shopping trip :-)
*** Bug 27560 has been marked as a duplicate of this bug. ***
No longer blocks: 27560
I don't ever hang on Win98. Can you give me steps to reproduce on NT?
Here is some clue or info: 1) If I backup Hyatt's change in addressWidgetOverlay.xul version 1.16 about snapping the tree widget to a certain row height, I don't freeze anymore! 2)on Mac (with or without the modification mentioned in point 1), open a new msg compose window, type something in the first recipient (do not press return), then select the menu item options/Select addresses. We also hit an infinite reflow loop but this time we get the following assert (inside the loop): ###!!! ASSERTION: Reflowing tree row group with unconstrained height!!!!: '!aReflowState.unconstrainedHeight',file s:\mozilla\layout\xul\base\src\nsTreeRowGroupFrame.cpp, line 1013 If I do the same on NT, we don't hang but we get the same assert preceded by some warnings: WEBSHELL+ = 8 (76B02E0) WARNING: XXX Fix me!! Converting Dirty to Resize!! Table need to implement reflow Dirty!!, file s:\mozilla\layout\xul\base\src\nsTre eOuterFrame.cpp, line 115 WARNING: Inefficient XUL: Reflowing outer tree frame with unconstrained width, try giving it a width in CSS!, file s:\mozilla\layout \xul\base\src\nsTreeOuterFrame.cpp, line 125 WARNING: Inefficient XUL: Reflowing outer tree frame with unconstrained height, try giving it a height in CSS!, file s:\mozilla\layo ut\xul\base\src\nsTreeOuterFrame.cpp, line 132 onload top.composeWindow: [object Window] onload toAddress: a2 <a2@netscape.com> WARNING: Inefficient XUL: Reflowing outer tree frame with unconstrained width, try giving it a width in CSS!, file s:\mozilla\layout \xul\base\src\nsTreeOuterFrame.cpp, line 125 WARNING: Inefficient XUL: Reflowing outer tree frame with unconstrained height, try giving it a height in CSS!, file s:\mozilla\layo ut\xul\base\src\nsTreeOuterFrame.cpp, line 132 ###!!! ASSERTION: Reflowing tree row group with unconstrained height!!!!: '!aReflowState.unconstrainedHeight', file s:\mozilla\layou t\xul\base\src\nsTreeRowGroupFrame.cpp, line 1013 Lost focus.
to reproduce this, on linux and NT, all i have to do is click the ``reply all'' button when there are two or more recipients (one of them being me). I've also noticed that when the addressbook tries to fill in the real name of an email address i've entered manually, i get a similarly behaved hang.
Assignee: hyatt → buster
Status: ASSIGNED → NEW
Typing for hyatt: nsGfxTextControlFrame is reflowing infinitely. Won't happen in debugger, use printfs. Looks like a ender bug. Have fun!
*** Bug 28322 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] → [PDT+] UNKNOWN
Hyatt.is.taking.this
Assignee: buster → hyatt
Thisisacomment
As it turns out, this happens for me in the debugger on linux (redhat 6.1, kernel 2.2.12, gdb 4.17.0.11-6)
*** Bug 28481 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Fix checked in that stops the hang when entering addresses individually. I don't yet have a fix for the Reply All hang (which happens on both Mac and Linux).
Fully fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
mail users everywhere thank you tremendously..
Fenella is trying this out (since Laurel is out today). So far, found http://bugzilla.mozilla.org/show_bug.cgi?id=28720 - don't know if related to this.
So let me get this straight... this bug is to be considered fixed, although the Reply All problem (this bug's original description) is not fixed. ?? Does that mean bug #28720 is now taking the place of the Reply All scenario?
OK using: 2000-02-22-11m14 mozilla build on linux rh 6.0 2000-02-22-08m14 commercial build on mac OS 9.0 2000-02-22-08m14 commercial build on NT 4.0 Verified adding more than 3 recipients and entering or tabbing to subject line, body of compose window. Can access and edit addressees again. Close/Send OK, no hang. Verified Reply All to message having more than 3 addressees. All seems to be okay there, too (ref bug #28720). Closing.
Status: RESOLVED → VERIFIED
Depends on: 30942
No longer depends on: 30942
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.