2000-01-10-09-M13 commercial build: 1) Login to mail. 2) Actual results: Repeat for selecting/highlighting folders/messages will display abnormal blank. Expected results: should highlight folder/messages as normal.

This problem happened on WinNT.

This problem not only happened on IMAP, it occurred on POP, too.

Hyatt did a bunch of stuff in the tree last weekend. Reassigning to him.

*** Bug 23565 has been marked as a duplicate of this bug. ***

Adding my comments from bug 23565, and changing OS to All (it occurs on Linux too): In today's build, if I click once on a bookmark in the side panel or in the bookmarks window, the entire row disppears (white). Forcing a repaint brings it back.

Tree control stuff - paulmac, does the QA contact belong to you?

*** Bug 23566 has been marked as a duplicate of this bug. ***

I just noticed that menus on linux SOMETIMES make the region of the tree underneath the folder fail to repaint... it doesn't happen very often though...

This affects Aim as well...cc'ing prass, amusil, scalkins

The incorrect rendering causes too much confusion to our users.

Hey Chris K., got any ideas? :)

It could be a table incremental reflow problem but I can't run mail/news right now to determine that. I haven't made any table changes in the last few days related to this, however.

The inner cell frame of trees had been box frames for a while. I reverted them back to blocks (which is what tables use). That's when it started showing up. So this could be a lurking remnant of your checkin a few weeks ago, or maybe something else entirely. Not sure. :)

karnaze-- you can also see the problem in bookmarks, if you can't run mailnews.

*** Bug 23645 has been marked as a duplicate of this bug. ***

You can see the problem in Account Setup by selecting the panels on the left (Server, Copies and Folders).

I only see this problem in mailnews. My bookmarks work just fine. I tried swapping between boxes and blocks as the inner cell frame, and it made no difference. The rows still vanish. I'm baffled.

data point: when I resize and make the window wider (or narrower), the row comes back

I start to see this problem in today's Linux build too. (2000-01-12-08 M13)

Same problem occurred on Today's Mac "2000-01-12-08-M13netscape5-mac-M13.sea.bin" build, too.

*** Bug 23618 has been marked as a duplicate of this bug. ***

The bookmarks will always disappear under this one condition; you have to expand enough folders to cause the sidebar's scrollbar to come up. Once that sucker comes up, just clicking on any bookmark makes it disappear. Once you close all of the expanded folders, the scrollbar stays and bookmarks still disappear when clicked.

*** Bug 23863 has been marked as a duplicate of this bug. ***

Fixed.

Is bug the same as where collapsing and reopening the sidebar makes all your bookmarks disappear? This only happens if you open enough parents to cause a scrollbar in the sidebar. Then collapse the sidebar while scrollbar is present. On reopening sidebar, bookmarks are blank. Build 2000011908.

The problem of selecting folders and messages is fine using: 2000-01-20-08m13 commercial build on linux 6.0 2000-01-20-08m13 commercial build on NT 4.0

OK using 2000-01-20-08m13 mozilla build on mac OS 8.5.1

Reopen this bug since problem occurred on Linux 2000-01-21-08-M13 commercial build

This also appears to have regressed from 1/20 to 1/21. beard, your stuff was backed out, I presume?

Comment made in another bug that's probably also relevant to this one. "Backing out beard's change 3.18 yesterday to mozilla/view/src/nsViewFactory.cpp fixes this problem. Adding beard to the CC list."

*** Bug 24683 has been marked as a duplicate of this bug. ***

Win32 (2000-01-21-08 M13) This problem also occurs on Win_nt 4.0. using today's build.

Giving to beard. He fixed it earlier. He can fix it again. i have faith. :)

This will be fixed after my next check-in.

Should this go into M13 branch?

*** Bug 24745 has been marked as a duplicate of this bug. ***

*** Bug 24898 has been marked as a duplicate of this bug. ***

*** Bug 24826 has been marked as a duplicate of this bug. ***

This is in todays M13 candidate. Very bad, makes testing very difficult. Woudl like fixed in M13 branch please. Select in any tree with scrollbar and lists disappear.

Setting to M13 per pdt, we would like the fix in M13...gonna try :-) If good...yes!...if not we will back out.

beard, please go ahead and check in on branch and trunk per chofmann!

So it turns out beard's checkin on the m13 branch last night was to fix bug 21966 and didn't end up fixing this one. He is talking to hyatt and will update this bug when he has more info. It is likely, however, that the fix will not be trivial and thus may take awhile (per beard).

Hyatt, was there something you were gonna do to the tree to compensate for the changes beard landed (which fixed bug 21966)? If so, the M13 boat has probably left the dock without the compensating changes to tree code. /be

Checked in workaround fix to mozilla/layout/xul/base/src/nsTreeOuterFrame.cpp, with hyatt's review. Here's the patch: Index: mozilla/layout/xul/base/src/nsTreeOuterFrame.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/xul/base/src/nsTreeOuterFrame.cpp,v retrieving revision 1.13 retrieving revision 1.13.8.1 diff -w -u -2 -r1.13 -r1.13.8.1 --- nsTreeOuterFrame.cpp 2000/01/17 03:56:46 1.13 +++ nsTreeOuterFrame.cpp 2000/01/26 03:28:28 1.13.8.1 @@ -73,10 +73,6 @@ nsIFrame* aPrevInFlow) { - nsresult rv = nsTableOuterFrame::Init(aPresContext, aContent, aParent, aContext, aPrevInFlow); - CreateViewForFrame(aPresContext,this,aContext,PR_TRUE); - nsIView* view; - GetView(aPresContext, &view); - view->SetContentTransparency(PR_TRUE); - return rv; + /* M13: don't create a view to prevent a serious cosmetic problem. bug=23530, r=hyatt, a=choffman */ + return nsTableOuterFrame::Init(aPresContext, aContent, aParent, aContext, aPrevInFlow); }

Verified on WinNT 2000-01-25-20-M13 commercial build: Selecting/highlighting Mail folders/messages is not displaying blank now... Will verify on Linux & Mac later

Linux is OK for 2000-01-25-20-M13 commercial build, too.

Verified on Mac 2000-01-26-03-M13 commercial build Selecting/highlighting Mail folders/messages is back to normal now....

Laurel, hope you don't mind that I am marking as verified for this bug. If you see this problem again, please reopen that!! Thanks.

Marking as verified!!

Reopening... seeing this using m14 build: 2000-01-27-08 commercial on NT 4.0. and linux 6.0, assume in mac, too.

Clearing fixed resolution for reopen state.

Something happened to my reopened state, went back to resolved. Now I'll reopen again.

I someone working on this for M14 or do we have to alter target milestone?

good catch. I'm clearing the target milestone since M13 went out the door, so that patrick can set it to what he wants

*** Bug 25968 has been marked as a duplicate of this bug. ***

*** Bug 25993 has been marked as a duplicate of this bug. ***

Adding myself to the CC list.

*** Bug 26127 has been marked as a duplicate of this bug. ***

*** Bug 26143 has been marked as a duplicate of this bug. ***

This is a beta1 stopper (obviously).

since we're using keywords now, I'm adding dogfood to the keyword field.

*** Bug 26780 has been marked as a duplicate of this bug. ***

Also affects IM. I filed a bug earlier today that was marked a duplicate of this one.

*** Bug 26957 has been marked as a duplicate of this bug. ***

*** Bug 27004 has been marked as a duplicate of this bug. ***

We're still seeing this in AIM. Please see Bugsplat Bug 384498 for more info.

Just so there's no confusion as to the current state of this (I see some "verification" text in status whiteboard): Still have this problem in mail/news window's thread and folder panes using 2000-02-09-08m14 commercial builds on linux, mac and NT.

When might we get a fix for this? Setting target mileston to M14, since nobody else did.

*** Bug 27541 has been marked as a duplicate of this bug. ***

What's the target fix date for this?

This is fixed with nsViewManager2. This will become the default view manager in M14.

Will nsViewManager2 be included in next builds, or will there be a delay, say until M14 candidates? If there will be some delay, is there perhaps a bug pertaining to nsViewManager2 so I know when it's in?

*** Bug 27957 has been marked as a duplicate of this bug. ***

Reopening, since a new bug was filed against me that said this still happens.

It is now the default view manager. Check the prefs. If it isn't checked in your Debug panel, check it and verify. I checked this last night myself.

OK. I've verified on mac,linux and NT with feb16 builds that this is fixed based on the condition beard set forth, that ViewManager2 is enabled in prefs (Edit|Prefs|Debug|use ViewManager2). 1. With today's builds, the default for new profiles and newly migrated profiles is to use ViewManager2. 2. Using default/new profiles/newly migrated profiles, the problem does not occur. 3. If I uncheck the profile, close mail window and open mail window, the problem resurfaces. Enable it again, close mail window and open again will correct problem. Based on all the above, I'm calling this bug verified using: 2000-02-16-08m14 commercial build on mac OS 9.0 2000-02-16-08m14 mozilla build on NT 4.0 2000-02-16-08m14 mozilla build on linux rh6.0

Clarification on my point #3 in comments above: Typo: "If I uncheck the profile..." Should read: "If I uncheck the pref..."

paulmac - we only verified the mail cases; you may wish to verify the bookmark cases.

yes, it's all good everywhere in browser land