Closed Bug 23530 Opened 25 years ago Closed 25 years ago

Selecting/highlighting displays blank

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: huang, Assigned: beard)

References

Details

(Whiteboard: [PDT+]) 

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.
Assignee: phil → hyatt
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. ***
OS: Windows NT → All
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.
QA Contact: lchiang → paulmac
Hardware: PC → All
Severity: major → critical
Summary: [BLOCKER]Repeat for selecting/highlighting folders will display abnormal blank → [DOGFOOD]Repeat for selecting/highlighting folders will display abnormal blank
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...
QA Contact: paulmac → lchiang
This affects Aim as well...cc'ing prass, amusil, scalkins
Status: NEW → ASSIGNED
Target Milestone: M13
Whiteboard: [PDT+]
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).
QA Contact: lchiang → laurel
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. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This also appears to have regressed from 1/20 to 1/21.  beard, your stuff was 
backed out, I presume?
Status: REOPENED → ASSIGNED
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.
Assignee: hyatt → beard
Status: ASSIGNED → NEW
Giving to beard.  He fixed it earlier.  He can fix it again.  i have faith. :)

This will be fixed after my next check-in.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] [PENDING CHECKIN]
Target Milestone: M13 → M14
Should this go into M13 branch?
*** Bug 24745 has been marked as a duplicate of this bug. ***
Blocks: 24854
*** 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.
Summary: [DOGFOOD]Repeat for selecting/highlighting folders will display abnormal blank → [DOGFOOD]Selecting/highlighting displays blank
Setting to M13 per pdt, we would like the fix in M13...gonna try :-)  If 
good...yes!...if not we will back out.
Target Milestone: M14 → M13
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Marking as verified!!
Status: RESOLVED → VERIFIED
Whiteboard: [PDT+] [PENDING CHECKIN] → [PDT+] verified fix on all the platforms
Reopening... seeing this using m14 build:  2000-01-27-08 commercial on NT 4.0.
and linux 6.0, assume in mac, too.
Status: VERIFIED → REOPENED
Clearing fixed resolution for reopen state.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Something happened to my reopened state, went back to resolved. Now I'll reopen
again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Target Milestone: M13
*** 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.
Keywords: dogfood
Summary: [DOGFOOD]Selecting/highlighting displays blank → Selecting/highlighting displays blank
*** 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.
Target Milestone: M14
When might we get a fix for this?
Setting target mileston to M14, since nobody else did.
Whiteboard: [PDT+] verified fix on all the platforms → [PDT+]
*** 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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.