Message (bottom) pane of 3-pane not repainted (when selecting folder, expand from collapsed state)

VERIFIED FIXED in mozilla1.4final

Status

SeaMonkey
MailNews: Message Display
P2
normal
VERIFIED FIXED
14 years ago
13 years ago

People

(Reporter: Karsten Düsterloh, Assigned: roc)

Tracking

({regression})

Trunk
mozilla1.4final
x86
Windows 2000
regression
Dependency tree / graph
Bug Flags:
blocking1.4 +
blocking1.5b +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2][fixed on 1.4 branch only][still not fixed in 1.5 alpha], URL)

Attachments

(4 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030223
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030223

messagepane keeps account data fragments

Reproducible: Always

Steps to Reproduce:
1. In MailNews, select account in the folderpane (to the left). The
"E-Mail/Newsgroup", "Accounts", "Advanced Features" are shown in the messagepane
(lower right).
2. Select subfolder of the account.

Actual Results:  
Threadpane is displayed and updated, but messagepane has still fragments of (1.)
in it.

Expected Results:  
Show last read message or blank messagepane.

Selecting a message in the threadpane displays this message in messagepane
correctly.

Comment 1

14 years ago
I also see this on the 02-23 trunk build, w2k.  The 02-21 build does not have
this problem.  Same problem as reported in bug 194667.

It does appear to be a painting problem - minimize or hide the mail window and
message preview pane is correctly painted when the window is restored.

Comment 2

14 years ago
*** Bug 194667 has been marked as a duplicate of this bug. ***

Comment 3

14 years ago
Confirming.  I see this on XP.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

14 years ago
Confirming. It's still there in my 1.4a build 2003032508 on WinNT4.

Comment 5

14 years ago
*** Bug 200889 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Summary: Messagepane not refreshed when selecting folder → Message (bottom) pane of 3-pane not repainted (when selecting folder, expand from collapsed state)

Comment 6

14 years ago
Seeing this in Win98 SE, 1.4b build 20030411.

Comment 7

14 years ago
Any idea when this will be fixed, very annoying to say the least. Thanks

Comment 8

14 years ago
And to make matters even worse, this bug is now showing up in the latest
Thunderbird build of 04/23/03.
on it.
Status: NEW → ASSIGNED
Keywords: nsbeta1, regression
Target Milestone: --- → mozilla1.4beta
as the summary indicated, it's appears to be a paint bug 
(or view manager? pardon my ignorance)

because if I move off screen, it gets repainted.
this reminds me of another bad regression, where the message pane doesn't repaint.

I bet they are related, let me go find it...
Yes, there is another bug like this. But I think this is Windows only. Need help
from kmcclusk.
similar to bug #183701, I think.

Comment 14

14 years ago
*** Bug 163749 has been marked as a duplicate of this bug. ***

Comment 15

14 years ago
*** Bug 201755 has been marked as a duplicate of this bug. ***

Comment 16

14 years ago
Re: Jay Garcia's comment #8, this bug was also present in the Thunderbird build
of 04/16/03.

Comment 17

14 years ago
Also very similar to Bug 202723.

Comment 18

14 years ago
adt: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]

Comment 19

14 years ago
*** Bug 204536 has been marked as a duplicate of this bug. ***

Comment 20

14 years ago
just to be irritating, "me too", mozilla 1.4b/win32 release version :-)  adding
myself to cc list.
roc, I'm not sure if kmcclusk@netscape.com is going to be able to help.

do you have any suggestions on where to start?
Target Milestone: mozilla1.4beta → mozilla1.4final
aiming for 1.4 final
The most suspicious checkin between 2/21 2/23 is this one, mine:

http://bugzilla.mozilla.org/show_bug.cgi?id=190193

Try backing it out to see if it fixes the problem. It's small so that should be
easy.
Also, a screenshot might help.

Comment 25

14 years ago
Created attachment 122932 [details]
Screenshot

Go nuts. :)

Comment 26

14 years ago
Is this the same as bug 199606 ? 

Also, 202723 looks a lot like a dupe too.
Flags: blocking1.4+
(Reporter)

Comment 27

14 years ago
Created attachment 122968 [details]
Reporter's screenshot of 3-pane

Reporter's screenshot of 3-pane with main pane news fragments after selecting a
newsgroup, but before selecting a specific message

Comment 28

14 years ago
re: comment #26

I believe all 3 of these bugs (bug 194638, bug 199606, bug 202723) are one and
the same. They all involve transitioning from a state where the message pane is
not visible (and something else is in this part of the screen) to a state where
the message pane below the splitter bar is visible... but the contents of the
message paint is not re-painted with what the current state should be. You can
force a repaint in all these cases by manually dragging the splitter bar.

Comment 29

14 years ago
Robert, backing out your change does indeed fix the problem. Should we re-assign
this to you? Or...?
Backing out that patch is not the 'right' fix, but it may be the expedient one.
It should definitely be checked into the 1.4final branch if we haven't found a
real fix before we branch. It's very safe because it just makes us paint more.
It will slow down DHTML performance in some cases.

Now, for the 'right thing', the message pane should be repainted by some means
other than the code I changed. Someone (me) needs to figure out where that
should be happening but isn't.
Assignee: sspitzer → roc+moz
Status: ASSIGNED → NEW
Priority: -- → P2
*** Bug 199606 has been marked as a duplicate of this bug. ***
*** Bug 202723 has been marked as a duplicate of this bug. ***
> I believe all 3 of these bugs (bug 194638, bug 199606, bug 202723)
> are one and the same

I agree and I've marked them all dups of this one.

Comment 34

14 years ago
I agree with the duplication; what about bug 167468, which seems to grandfather 
all of these?

Comment 35

14 years ago
(from dup)
Steps to reproduce problem:
1. Open Mail
2. Collapse and reveal the message pane
Steps to reproduce problem:
1. Inspect something using DOM inspector
2. Collapse and reveal the right panel
Actual results: <browser> tag does not repaint, although other tags do
Expected result: Everything repaints

Comment 36

14 years ago
This also affects commercial side of netscape.  For folks internal to netscape
see http://bugscape.nscp.aoltw.net/show_bug.cgi?id=23476. 

Comment 37

14 years ago
I've seen this repaint problem in both email, venkman and in frames now in the
latest win32 1.4 builds on WinXP.

I see it normally when the view changes due to incremental resizing as the
content changes.   If elements shift left like a heading or a bold table, the
element ins partially painted with the first 10-16 pixels missing on the left
hand side of each element.

I'm working trying to work on a test case to demonstrate it in the browser as well.

Comment 38

14 years ago
Re: browser repainting issue - I found a problem with the page:

http://www.w3.org/Style/CSS/

in 1.4b release, but it seems to be fixed in rv:1.5a Gecko/20030529

Comment 39

14 years ago
This issue still remains though :-)
*** Bug 195931 has been marked as a duplicate of this bug. ***
roc wrote:

"Backing out that patch is not the 'right' fix, but it may be the expedient one.
It should definitely be checked into the 1.4final branch if we haven't found a
real fix before we branch. It's very safe because it just makes us paint more.
It will slow down DHTML performance in some cases.

Now, for the 'right thing', the message pane should be repainted by some means
other than the code I changed. Someone (me) needs to figure out where that
should be happening but isn't."

should we be preparing to back bug #190193?

anything I can do to help?
I think we should back out bug 190193 on the 1.4 branch but not on the trunk.

Comment 43

14 years ago
Created attachment 124567 [details] [diff] [review]
patch to backout roc's checkin to bug 190193

Updated

14 years ago
Attachment #124567 - Flags: superreview?(roc+moz)
Attachment #124567 - Flags: review?(dbaron)
Comment on attachment 124567 [details] [diff] [review]
patch to backout roc's checkin to bug 190193

r=dbaron, but in the future please generate backout patches using |cvs up
-j<R1> -j<R2>|.  (Or did you modify the indentation of the one line after doing
that?)
Attachment #124567 - Flags: review?(dbaron) → review+
seeking adt approval for this branch only backout.
Whiteboard: [adt2] → [adt2][seeking adt approval for branch only fix]

Comment 46

14 years ago
a=adt to land on 1.4 branch.
Whiteboard: [adt2][seeking adt approval for branch only fix] → [adt2]
I've landed the fix on the branch only.  

the fix will not be landing on the trunk.

the hope is that we can verify this fix (and bug #202595) for 1.4, and then
morph is bug into a 1.5 trunk bug.

not marking fixed, but I'll ping QA directly so they know to verify.
Blocks: 202595
Keywords: fixed1.4
Whiteboard: [adt2] → [adt2][fixed on 1.4 branch only][still not fixed in 1.5 alpha]
Depends on: 190193
No longer depends on: 190193
Depends on: 190193

Comment 48

14 years ago
I've noticed in 1.4rc1 that this bug does not appear when using the classic
theme. However, it does appear under every other theme I use - including modern.
I bleieve the other themes I am using are based on the modern theme.
>I've noticed in 1.4rc1 that this bug does not appear when using the classic
>theme.

Using 1.4rc1 on WinXP. I switched to Classic, and the bug is there. To recreate
it on 1.4rc1:
1: Click on an account that you haven't accessed yet.
2: Click on one of newsgroups or folders within that account.

When "Remember last selected message" is enabled, and you've already accessed a
certain folder or newsgroup, the bug will not appear when you access it again,
because Moz is will display the last selected message.

Comment 50

14 years ago
I think, it is the same source, but I will describe it, to ensure it:

- Using V1.4RC unter Win2000.
- Have junk folder within local folders
- selecting junk folder, no msg is selected, all have junk flag
- choose tools -> delete mail, marked as junk...
  -> all mails are deleted, but part/all of the first mail is shown in the
message pane

just tell me, in case it is of different nature. Then I will open a new bug.

Comment 51

14 years ago
Confirming bug still present with Modern and Pinball themes in Mozilla 1.4 RC1 /
win2k.  I haven't noticed any difference in how consistent the bug is.
MoellerPeter@web.de's bug is a different bug.

rc1 doesn't have this backout.

rc1 was released May 29, 2003, and I made this change to the branch on 5/30

you'd need a later 1.4 final build to test this.

Comment 53

14 years ago
Latest 1.5a doesn't have the fix. Is it supposed to?

Comment 54

14 years ago
Note to QA: When verifying this bug go to bug# 195931 and run scenarios listed
in commentss 4 and 6. 
> Latest 1.5a doesn't have the fix. Is it supposed to?

No. Only 1.4 branch.
Should this bug remain as a 1.4 blocker?

Comment 57

14 years ago
Could someone please provide a newbie with a link to a 1.4 final build that has
the fix? Everything I download post 29/05 from ftp turns out to be 1.5a.
> Could someone please provide a newbie with a link to a 1.4 final build that has
> the fix?

http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.4/
I'm sure there's a newsgroup, where you could ask such questions.
Comment on attachment 124567 [details] [diff] [review]
patch to backout roc's checkin to bug 190193

this was actually sr'ed by dbaron, I presume.
Attachment #124567 - Flags: superreview?(roc+moz) → superreview+
*** Bug 208308 has been marked as a duplicate of this bug. ***

Comment 61

14 years ago
Branch build 2003-06-04-05: WinMe
Verified on the branch.

- Selected a message, collapsed/expanded the message pane and the contents of
the message displayed as expected.

- Selected a message in the Inbox, selected the account level so that the
Account Central page appears to the right (links to Read Message, Compose a new
message etc...), reselected the Inbox and the contents of the message displayed
as expected.
Keywords: fixed1.4 → verified1.4

Comment 62

14 years ago
*** Bug 203037 has been marked as a duplicate of this bug. ***

Comment 63

14 years ago
Bug 190193 also caused the bug 195598 - was that bug fixed on 1.4 branch too
when this one was fixed?

Comment 64

14 years ago
Using 1.4 RC2 / win32, I haven't seen any repainting problems so far.

Comment 65

14 years ago
The similar problem described in bug 167468 (dupe'd by bug 183701) has not been 
fixed in RC2.
Blocks: 207477
In order to reproduce this bug, I had to change two preferences from the defaults:
 * in "Mail & Newsgroups" uncheck "When Mail launches, show the Start Page in
the message area"
 * in "Mail & Newsgroups" | "Windows", change the three-pane layout to the
version with the half-length sidebar  (A bunch of reports and screenshots,
although a minority, show the problem in the default layout, but I don't see it
there.  Some reports also suggest that one has to set the pref this way.)

The bug in bug 167468 may be distinct, or may not be.

The debugging patch in bug 207477 comment 12 does NOT allow me to see the bug on
Linux.
Flags: blocking1.5a?

Comment 67

14 years ago
re: comment 66 - I have the start page option unchecked, but I have the full
length mail folder pane.

I used to get the problem, but not since 1.4 RC2.

Comment 68

14 years ago
Of course, it's fixed on 1.4 branch.

IMHO, this is a choice - do we want bug 190193 fixed or all the other ones that
it caused? I think that bug 190193 is less times reported than all regressions
that it caused (including bug 195598).

If it was my choice, I would regress it and wait for the better fix.
Blocks: 195598
(Reporter)

Comment 69

14 years ago
I can still see this bug with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.5a) Gecko/20030710, Classic theme.
(It's fixed on the 1.4 branch.)
+--+--+  
|  |  |  Re comment 66:
|  +--+
|  |  |    - the mailnews start page setting is irrelevant (for me)
+--+--+  <-- as stated in the initial description, I'm using the default 3pane

Comment 70

14 years ago
I can reproduce this without mail news involvement at all:

http://www.kaply.com/work/bugzilla/webmail

Click on the expand button. The right side should show 2's, but it doesn't paint.

This is a major fix for IBM. What's going on with this?
No longer blocks: 195598
We either need a way to reproduce this on Linux, or a developer with a Windows
build to do some debugging...
In particular, it would be nice if someone could check whether this Invalidate()
call is firing for the new frame:

http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/nsFrameFrame.cpp#586

Comment 73

14 years ago
That invalidate gets hit in both cases the same number of times.

Roc, I could probably setup desktop on call for you to remote debug this :)
That might be worth doing.

Another question: if you force a repaint after the expand by covering and
uncovering the window, the window is painted correctly, right?

Comment 75

14 years ago
yes. Overlaying causes a repaint, as does any selection.
This is quite baffling. Resizing the view should cause the new area (in this
case, the entire frame #2) to be repainted, both because of the explicit
invalidates inside nsViewManager::ResizeView and because of the resizing of the
native widget.

It might be helpful to obtain a debug build and see what we can see using paint
flashing. You can turn on paint flashing in preferences, under "Debug | Events".
You may want to see the flash delay in gfx/src/windows/nsWindow.cpp to something
larger than the default of 1000000, which is a bit short for detailed analysis
(this is around the call to debug_WantPaintFlashing). What we want to find out
is the order in which widgets get painted and what gets painted at each step.

Comment 77

14 years ago
mozilla1.5a released. unsetting blocking request.
Flags: blocking1.5a? → blocking1.5b?
I've been working on this via Mike Kaply's machine. Some notes: the code in
nsFrameOuterFrame::Reflow that Invalidates the frame is wrong; it should
invalidate the union of the old and new rects, not just the old rect. But fixing
that doesn't fix the problem, because the invalidation happens in the FRAMESET
document's widget and the area is subsequently covered by the resized widget for
the FRAME.

The Reflow of the nsFrameInnerFrame resizes the nsDocumentViewer's widget with
PR_FALSE for the repaint flag; the comment in nsDocumentViewer.cpp says that
reflow should invalidate any areas that need to be repainted after the resize.
This is true... but it's not happening.

There is some code in widget/src/nsWindow.cpp, in the handling of
WM_WINDOWPOSCHANGED, that seems intended to force repainting of any newly added
window area. But it's broken because it builds a rect relative to mWnd's parent
window origin and then passes it to ::RedrawWindow(mWnd, ...), which expects a
rect in mWnd's coordinate system. So that doesn't do anything helpful. That code
should probably be removed entirely since whatever it's supposed to do, it can't
be working reliably.

So, that brings us to the fact that resize reflows of the canvas frame aren't
resulting in a repaint of the new area. This isn't showing up as a problem on X
because on X, resizing a widget always invalidates the new area (there doesn't
seem to be a way to turn that off). We should try to find a way to at least
paint that new area with something bogus so these bugs can be reproduced on X.
I'll have a look at that --- and the real bug --- tomorrow.

Updated

14 years ago
Flags: blocking1.5b? → blocking1.5b+
OK, I tracked down the bug last week. The problem is that the framed document is
being properly invalidated, but during the invalidations the widget for the
frame element (which is the parent of the root widget for the document) has size
(0,0) because nsFrameInnerFrame reflows the enclosed document before resizing
the view for the nsFrameInnerFrame. Thus the invalidates are dropped because the
widgets being invalidated have empty clip area. Now, when the nsFrameInnerFrame
view (and widget) are resized, its child widget for the framed document should
be invalidated --- but it is not. In nsViewManager::ResizeView, the call to
nsView::SetDimensions passes PR_FALSE to aPaint, so the widget system does not
invalidate newly exposed area in the children (on Windows only --- all other
platforms ignore the aPaint flag on nsIWidget::Resize and invalidate anyway).
This is incorrect: all child widgets MUST be invalidated over their newly
exposed areas, because (as in this case) there could be pending invalidates
intended for those areas which have been dropped. So we need to pass PR_TRUE to
nsView::SetDimensions. (nsViewManager::ResizeView often covers up this bug
because it manually invalidates the changed area via calls to UpdateView, but
that isn't enough because it doesn't send invalidates to widgets in different
view hierarchies. That code is for the case where aView does not have a widget
(and is not a leaf view with a separate view hierarchy under it.))
Created attachment 129965 [details] [diff] [review]
fix

Given all that, the fix is quite easy... I haven't tested this yet because I
haven't had access to a Windows box since I figured it out.
I can't actually imagine when it would be correct to resize a widget and not
paint the changed area in the widget and all its descendant widgets. Especially
since Windows is the only platform that tries to implement aPaint==PR_FALSE, we
should probably just get rid of that parameter and always paint the changed area.
Comment on attachment 129965 [details] [diff] [review]
fix

We should probably get this into 1.5b if we can. I think the risk is incredibly
low.
Attachment #129965 - Flags: superreview?(dbaron)
Attachment #129965 - Flags: review?(dbaron)
Attachment #129965 - Flags: approval1.5b?
Comment on attachment 129965 [details] [diff] [review]
fix

We should probably get this into 1.5b if we can. I think the risk is incredibly
low.

Mkaply says that this patch fixes the bug for him.
Attachment #129965 - Flags: superreview?(dbaron)
Attachment #129965 - Flags: superreview+
Attachment #129965 - Flags: review?(dbaron)
Attachment #129965 - Flags: review+
Attachment #129965 - Flags: approval1.5b? → approval1.5b+
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 85

14 years ago
*** Bug 214988 has been marked as a duplicate of this bug. ***

Comment 86

14 years ago
(sorry, erroneous dupe)

Comment 87

14 years ago
v
Status: RESOLVED → VERIFIED

Updated

14 years ago
Blocks: 195598
This seems to have caused bug 220698
And bug 224607 
Depends on: 220698, 224607
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.