Closed Bug 21703 Opened 25 years ago Closed 25 years ago

[dogfood]Folders autocollapse after expanding them

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: scottputterman, Assigned: hyatt)

References

Details

(Whiteboard: [PDT+] Can't even begin to estimate. Don't even understand the problem yet.)

Open up mailnews.
Open the twisty on a server.  Select a folder.  The twisty will close itself.
If it doesn't happen by doing this, select a message.  This is usually enough to
make this happen.
*** Bug 21717 has been marked as a duplicate of this bug. ***
I see this problem in today commercial seamonkey builds win32 1999-12-14-09-m12
and macos 1999-12-14-08-m12.  I did not test Linux.  This occurs under POP.  Sol
reported this issue using IMAP on win32.

Work around: I have to manually collapse and expand the list of folders to have
them displayed again.
Build 1999121408M12: NT4, Mac
Esther and I are both seeing this on todays build.

On my system running NT4,I noticed with a profile using an IMAP account and
6 News accounts, after selecting the Inbox it prompts for a password and
it retrives messages. This is when the IMAP account collapses and all the News
accounts disappear (only the IMAP top level is displayed). When I expand the
IMAP account then all the folders and accounts reappear. The collapsing problem
also occurs when I select another folder in the IMAP account.
Putting on PDT+ radar.
Whiteboard: [PDT+]
Status: NEW → ASSIGNED
QA Contact: lchiang → huang
Severity: normal → critical
OS: other → All
Priority: P3 → P1
Hardware: PC → All
Problems also seen on Linux latest respin build 12-14-11-M12 commercial build
for both IMAP & POP accounts.
Changed platforms & OS to All!! Changed QA Contact to me!!
Severity: critical → blocker
Summary: [dogfood]Folders autocollapse after expanding them → [BLOCKER][dogfood]Folders autocollapse after expanding them
upgrading to blocker.  We can't test or use mail without seeing folders.
*** Bug 21727 has been marked as a duplicate of this bug. ***
This problem also happened on news/newsgroup.
But, overall, I still can see the folders and do some other testing, this
problem keep happening intermittent.
Assignee: karnaze → hyatt
Status: ASSIGNED → NEW
Reassigning to Hyatt who has agreed to take the bug.
This affects AIM as well. cc'ing amusil,scalkins,prass
Summary: [BLOCKER][dogfood]Folders autocollapse after expanding them → [dogfood]Folders autocollapse after expanding them
Target Milestone: M12
targetting p1 for m12, removing extraneous 'BLOCKER' from summary.
FWIW, I don't see this using IMAP on Win98, MacOS 8.6 or RH 6.0.
*** Bug 21733 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
I am baffled.  This has to do with karnaze's recent changes, but I can't track
it down.  Both the file tree and the mailnews tree are affected.  The frames
aren't really getting destroyed... they're just somehow being lost, either
during the flow or the paint.

I suspect it has something to do with reflow.  If I had to guess, it might have
something to do with nested row groups.
Whiteboard: [PDT+] → [PDT+] Can't even begin to estimate. Don't even understand the problem yet.
Ok, I have a clearer idea of what's happening in mail at least.  Whenever my
IMAP Inbox folder goes from bold text to regular text (or vice versa), the tree
gets an incremental reflow performed on it.

I suspect that karnaze has made some changes to incremental reflow (in
particular to style changed incremental reflows) that do the wrong thing with
nested row groups.
Hyatt forgot to mention that a crude workaround is to resize the window
vertically.
Yes, forcing a resize reflow will make things show up.
I think there's a crash associated with this.  When I browse my file system, if
I open a folder and then click on the twisty for a subfolder, the folder closes
up.  When I click on the folder's twisty again to open it up, I get the
following crash,

nsXULElement::GetParentNode(nsXULElement * const 0x03522830, nsIDOMNode * *
0x0012f558) line 655 + 24 bytes
GetNodeBracketPoints(nsIContent * 0x03522820,
nsCOMPtr<nsIDOMNode> * 0x0012f558, int * 0x0012f560, int * 0x0012f564) line 248
CompareNodeToRange(nsIContent * 0x03522820, nsIDOMRange * 0x03a796c0, int *
0x0012f5c4, int * 0x0012f5c0) line 195 + 21 bytes
nsContentSubtreeIterator::GetTopAncestorInRange(nsCOMPtr<nsIContent> {...},
nsCOMPtr<nsIContent> * 0x03a7803c) line 1076 + 34 bytes
nsContentSubtreeIterator::Init(nsContentSubtreeIterator * const 0x03a78030,
nsIDOMRange * 0x03a796c0) line 919 + 27 bytes
nsDOMSelection::selectFrames(nsDOMSelection * const 0x034726c0, nsIPresContext *
0x03450040, nsIDOMRange * 0x03a796c0, int 0) line 2272
nsDOMSelection::Clear(nsIPresContext * 0x03450040) line 2123
nsDOMSelection::Collapse(nsDOMSelection * const 0x034726c0, nsIDOMNode *
0x02f02700, int 1) line 2799
nsRangeList::TakeFocus(nsRangeList * const
0x03472720, nsIContent * 0x02f026f0, unsigned int 1, unsigned int 2, int 0, int
0) line 1430
nsRangeList::HandleClick(nsRangeList * const 0x03472720, nsIContent
* 0x02f026f0, unsigned int 1, unsigned int 2, int 0, int 0, int 1) line 1329
nsFrame::HandlePress(nsFrame * const 0x01353d10, nsIPresContext * 0x03450040,
nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 857
nsFrame::HandleEvent(nsFrame * const 0x01353d10, nsIPresContext * 0x03450040,
nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 814
nsTitledButtonFrame::HandleEvent(nsTitledButtonFrame * const 0x01353d10,
nsIPresContext * 0x03450040, nsGUIEvent * 0x0012fb68, nsEventStatus *
0x0012fa74) line 1198
PresShell::HandleEvent(PresShell * const 0x03472794,
nsIView * 0x03472e50, nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line
2649 + 38 bytes
nsView::HandleEvent(nsView * const 0x03472e50, nsGUIEvent *
0x0012fb68, unsigned int 28, nsEventStatus * 0x0012fa74, int & 0) line 841
nsViewManager::DispatchEvent(nsViewManager * const 0x03474220, nsGUIEvent *
0x0012fb68, nsEventStatus * 0x0012fa74) line 1678
HandleEvent(nsGUIEvent *
0x0012fb68) line 69
nsWindow::DispatchEvent(nsWindow * const 0x03472d24,
nsGUIEvent * 0x0012fb68, nsEventStatus & nsEventStatus_eIgnore) line 421 + 10
bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb68) line 442
nsWindow::DispatchMouseEvent(unsigned int 302, nsPoint * 0x00000000) line 3332 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 302, nsPoint * 0x00000000)
line 3550
nsWindow::ProcessMessage(unsigned int 513, unsigned int 1, long
6750216, long * 0x0012fdc8) line 2627 + 24 bytes
nsWindow::WindowProc(HWND__ *
0x003f0780, unsigned int 513, unsigned int 1, long 6750216) line 608 + 27 bytes
USER32!
*** Bug 21817 has been marked as a duplicate of this bug. ***
When testing in news I discovered that it only seems to happe when the
server/group pane needs to change the number of unread messages.  If I click on
a newsgroup that has some unread messages and tehn I click on a header of an
unread header then the list of newsgroups disappears.  If I click on a newsgroup
with no new messages and click on an already read message then the
newsgroup/servers in the left pane stay visible.
I think what is happening is that when teh message count in the
server/folder/group pane needs refreshing is is getting lost (disappearing).
When it doesn't need refreshing/updating tehn no action in the header or message
pane cause the groups/folders to disappear.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Verified on Linux 12-16-12-M12 commercial build.
Works OK. The Folders is not autocollapsing after expanding now.
Will check WinNT later...
Status: RESOLVED → VERIFIED
Verified on WinNT & Mac 12-16-12-M12 commercial build.
Work OK for the fix of this bug for both WinNT & Mac.
But, still had crashes for start the Seamonkey on the Mac - not stable yet!!
Still Mark as verified for this bug!!
*** Bug 21871 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.