Closed
Bug 21703
Opened 25 years ago
Closed 25 years ago
[dogfood]Folders autocollapse after expanding them
Categories
(SeaMonkey :: MailNews: Message Display, defect, P1)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
VERIFIED
FIXED
M12
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.
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.
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
QA Contact: lchiang → huang
Updated•25 years ago
|
Severity: normal → critical
OS: other → All
Priority: P3 → P1
Hardware: PC → All
Comment 5•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: karnaze → hyatt
Status: ASSIGNED → NEW
Comment 9•25 years ago
|
||
Reassigning to Hyatt who has agreed to take the bug.
Comment 10•25 years ago
|
||
This affects AIM as well. cc'ing amusil,scalkins,prass
Updated•25 years ago
|
Summary: [BLOCKER][dogfood]Folders autocollapse after expanding them → [dogfood]Folders autocollapse after expanding them
Target Milestone: M12
Comment 11•25 years ago
|
||
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.
Assignee | ||
Comment 12•25 years ago
|
||
*** Bug 21733 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 13•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] Can't even begin to estimate. Don't even understand the problem yet.
Assignee | ||
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
Hyatt forgot to mention that a crude workaround is to resize the window vertically.
Assignee | ||
Comment 16•25 years ago
|
||
Yes, forcing a resize reflow will make things show up.
Reporter | ||
Comment 17•25 years ago
|
||
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!
Assignee | ||
Comment 18•25 years ago
|
||
*** Bug 21817 has been marked as a duplicate of this bug. ***
Comment 19•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 20•25 years ago
|
||
Verified on Linux 12-16-12-M12 commercial build. Works OK. The Folders is not autocollapsing after expanding now. Will check WinNT later...
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 21•25 years ago
|
||
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!!
Comment 22•25 years ago
|
||
*** Bug 21871 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•