Closed Bug 194638 Opened 22 years ago Closed 22 years ago

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

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4final

People

(Reporter: mnyromyr, Assigned: roc)

References

(
URL
)

Details

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

Attachments

(4 files)

Screenshot
42.19 KB, image/gif
Details
Reporter's screenshot of 3-pane
81.85 KB, image/jpeg
Details
patch to backout roc's checkin to bug 190193
1.66 KB, patch
dbaron
: review+
roc
: superreview+
Details | Diff | Splinter Review
fix
1.07 KB, patch
dbaron
: review+
dbaron
: superreview+
dbaron
: approval1.5b+
Details | Diff | Splinter Review
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.
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.
*** Bug 194667 has been marked as a duplicate of this bug. ***
Confirming. I see this on XP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming. It's still there in my 1.4a build 2003032508 on WinNT4.
*** Bug 200889 has been marked as a duplicate of this bug. ***
URL: http://www.ufaq.org/display.jpg
Summary: Messagepane not refreshed when selecting folder → Message (bottom) pane of 3-pane not repainted (when selecting folder, expand from collapsed state)
Seeing this in Win98 SE, 1.4b build 20030411.
Any idea when this will be fixed, very annoying to say the least. Thanks
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.
*** Bug 163749 has been marked as a duplicate of this bug. ***
*** Bug 201755 has been marked as a duplicate of this bug. ***
Re: Jay Garcia's comment #8, this bug was also present in the Thunderbird build of 04/16/03.
Also very similar to Bug 202723.
adt: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
*** Bug 204536 has been marked as a duplicate of this bug. ***
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
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.
Attached image Screenshot —
Go nuts. :)
Is this the same as bug 199606 ? Also, 202723 looks a lot like a dupe too.
Flags: blocking1.4+
Reporter's screenshot of 3-pane with main pane news fragments after selecting a newsgroup, but before selecting a specific message
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.
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.
I agree with the duplication; what about bug 167468, which seems to grandfather all of these?
(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
This also affects commercial side of netscape. For folks internal to netscape see http://bugscape.nscp.aoltw.net/show_bug.cgi?id=23476.
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.
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
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.
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]
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]
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.
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.
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.
Latest 1.5a doesn't have the fix. Is it supposed to?
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?
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. ***
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
*** Bug 203037 has been marked as a duplicate of this bug. ***
Bug 190193 also caused the bug 195598 - was that bug fixed on 1.4 branch too when this one was fixed?
Using 1.4 RC2 / win32, I haven't seen any repainting problems so far.
The similar problem described in bug 167468 (dupe'd by bug 183701) has not been fixed in RC2.
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.
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.
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
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
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?
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
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?
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.
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.
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.))
Attached patch fix — — Splinter Review
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
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 214988 has been marked as a duplicate of this bug. ***
(sorry, erroneous dupe)
v
Status: RESOLVED → VERIFIED
Blocks: 195598
This seems to have caused bug 220698
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: