Last Comment Bug 194638 - Message (bottom) pane of 3-pane not repainted (when selecting folder, expand from collapsed state)
: Message (bottom) pane of 3-pane not repainted (when selecting folder, expand ...
Status: VERIFIED FIXED
[adt2][fixed on 1.4 branch only][stil...
: regression
Product: SeaMonkey
Classification: Client Software
Component: MailNews: Message Display (show other bugs)
: Trunk
: x86 Windows 2000
: P2 normal with 3 votes (vote)
: mozilla1.4final
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
: esther
:
Mentors:
http://www.ufaq.org/display.jpg
: 163749 194667 195931 199606 200889 201755 202723 204536 208308 (view as bug list)
Depends on: 190193 220698 224607
Blocks: 195598 202595 207477
  Show dependency treegraph
 
Reported: 2003-02-23 14:03 PST by Karsten Düsterloh
Modified: 2004-11-22 17:25 PST (History)
36 users (show)
asa: blocking1.4+
asa: blocking1.5b+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Screenshot (42.19 KB, image/gif)
2003-05-10 12:33 PDT, Mark Anderson
no flags Details
Reporter's screenshot of 3-pane (81.85 KB, image/jpeg)
2003-05-11 14:22 PDT, Karsten Düsterloh
no flags Details
patch to backout roc's checkin to bug 190193 (1.66 KB, patch)
2003-05-30 11:05 PDT, Suresh
dbaron: review+
roc: superreview+
Details | Diff | Splinter Review
fix (1.07 KB, patch)
2003-08-17 21:58 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
dbaron: review+
dbaron: superreview+
dbaron: approval1.5b+
Details | Diff | Splinter Review

Description Karsten Düsterloh 2003-02-23 14:03:23 PST
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 K Chayka 2003-02-24 06:16:53 PST
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 Mark Anderson 2003-02-24 23:13:01 PST
*** Bug 194667 has been marked as a duplicate of this bug. ***
Comment 3 Mark Anderson 2003-02-25 07:45:54 PST
Confirming.  I see this on XP.
Comment 4 OstGote! 2003-03-28 02:58:24 PST
Confirming. It's still there in my 1.4a build 2003032508 on WinNT4.
Comment 5 Daniel Wang 2003-04-07 17:22:32 PDT
*** Bug 200889 has been marked as a duplicate of this bug. ***
Comment 6 Grant Weir 2003-04-12 17:42:48 PDT
Seeing this in Win98 SE, 1.4b build 20030411.
Comment 7 jay garcia 2003-04-22 07:13:47 PDT
Any idea when this will be fixed, very annoying to say the least. Thanks
Comment 8 jay garcia 2003-04-24 08:03:53 PDT
And to make matters even worse, this bug is now showing up in the latest
Thunderbird build of 04/23/03.
Comment 9 (not reading, please use seth@sspitzer.org instead) 2003-04-24 09:36:35 PDT
on it.
Comment 10 (not reading, please use seth@sspitzer.org instead) 2003-04-24 11:31:26 PDT
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.
Comment 11 (not reading, please use seth@sspitzer.org instead) 2003-04-24 11:43:09 PDT
this reminds me of another bad regression, where the message pane doesn't repaint.

I bet they are related, let me go find it...
Comment 12 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-04-24 13:37:10 PDT
Yes, there is another bug like this. But I think this is Windows only. Need help
from kmcclusk.
Comment 13 (not reading, please use seth@sspitzer.org instead) 2003-04-24 14:04:48 PDT
similar to bug #183701, I think.
Comment 14 Mike Cowperthwaite 2003-04-24 17:51:31 PDT
*** Bug 163749 has been marked as a duplicate of this bug. ***
Comment 15 Mike Cowperthwaite 2003-04-24 17:53:15 PDT
*** Bug 201755 has been marked as a duplicate of this bug. ***
Comment 16 Grant Weir 2003-04-24 19:02:37 PDT
Re: Jay Garcia's comment #8, this bug was also present in the Thunderbird build
of 04/16/03.
Comment 17 Mike Cowperthwaite 2003-04-25 08:13:48 PDT
Also very similar to Bug 202723.
Comment 18 Samir Gehani 2003-05-05 17:38:49 PDT
adt: nsbeta1+/adt2
Comment 19 Mike Cowperthwaite 2003-05-07 10:14:39 PDT
*** Bug 204536 has been marked as a duplicate of this bug. ***
Comment 20 Mike Coppins 2003-05-08 08:11:20 PDT
just to be irritating, "me too", mozilla 1.4b/win32 release version :-)  adding
myself to cc list.
Comment 21 (not reading, please use seth@sspitzer.org instead) 2003-05-09 21:15:44 PDT
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?
Comment 22 (not reading, please use seth@sspitzer.org instead) 2003-05-09 21:19:19 PDT
aiming for 1.4 final
Comment 23 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-05-10 12:00:02 PDT
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.
Comment 24 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-05-10 12:13:25 PDT
Also, a screenshot might help.
Comment 25 Mark Anderson 2003-05-10 12:33:14 PDT
Created attachment 122932 [details]
Screenshot

Go nuts. :)
Comment 26 Asa Dotzler [:asa] 2003-05-11 12:41:09 PDT
Is this the same as bug 199606 ? 

Also, 202723 looks a lot like a dupe too.
Comment 27 Karsten Düsterloh 2003-05-11 14:22:33 PDT
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 Ed Grochowski 2003-05-12 09:37:00 PDT
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 David :Bienvenu 2003-05-12 10:53:51 PDT
Robert, backing out your change does indeed fix the problem. Should we re-assign
this to you? Or...?
Comment 30 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-05-12 14:00:52 PDT
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.
Comment 31 (not reading, please use seth@sspitzer.org instead) 2003-05-12 16:15:49 PDT
*** Bug 199606 has been marked as a duplicate of this bug. ***
Comment 32 (not reading, please use seth@sspitzer.org instead) 2003-05-12 16:15:59 PDT
*** Bug 202723 has been marked as a duplicate of this bug. ***
Comment 33 (not reading, please use seth@sspitzer.org instead) 2003-05-12 16:17:56 PDT
> 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 Mike Cowperthwaite 2003-05-12 16:47:40 PDT
I agree with the duplication; what about bug 167468, which seems to grandfather 
all of these?
Comment 35 neil@parkwaycc.co.uk 2003-05-13 07:04:56 PDT
(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 Suresh 2003-05-22 11:18:50 PDT
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 Thomas Swan 2003-05-29 15:52:58 PDT
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 Mike Coppins 2003-05-29 15:56:29 PDT
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 Mike Coppins 2003-05-29 15:57:48 PDT
This issue still remains though :-)
Comment 40 (not reading, please use seth@sspitzer.org instead) 2003-05-29 20:46:38 PDT
*** Bug 195931 has been marked as a duplicate of this bug. ***
Comment 41 (not reading, please use seth@sspitzer.org instead) 2003-05-29 20:51:05 PDT
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?
Comment 42 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-05-29 20:57:03 PDT
I think we should back out bug 190193 on the 1.4 branch but not on the trunk.
Comment 43 Suresh 2003-05-30 11:05:04 PDT
Created attachment 124567 [details] [diff] [review]
patch to backout roc's checkin to bug 190193
Comment 44 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2003-05-30 11:41:17 PDT
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?)
Comment 45 (not reading, please use seth@sspitzer.org instead) 2003-05-30 12:01:12 PDT
seeking adt approval for this branch only backout.
Comment 46 Samir Gehani 2003-05-30 12:05:35 PDT
a=adt to land on 1.4 branch.
Comment 47 (not reading, please use seth@sspitzer.org instead) 2003-05-30 12:50:36 PDT
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.
Comment 48 farcusnz 2003-05-30 22:18:09 PDT
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.
Comment 49 Chris Ilias [:cilias] 2003-05-30 22:47:36 PDT
>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 Peter Möller 2003-05-31 06:45:21 PDT
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 Mike Coppins 2003-06-01 11:49:31 PDT
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.
Comment 52 (not reading, please use seth@sspitzer.org instead) 2003-06-02 12:41:45 PDT
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 jay garcia 2003-06-02 16:25:41 PDT
Latest 1.5a doesn't have the fix. Is it supposed to?
Comment 54 Ninoschka Baca 2003-06-02 16:33:03 PDT
Note to QA: When verifying this bug go to bug# 195931 and run scenarios listed
in commentss 4 and 6. 
Comment 55 Chris Ilias [:cilias] 2003-06-02 17:47:24 PDT
> Latest 1.5a doesn't have the fix. Is it supposed to?

No. Only 1.4 branch.
Comment 56 Chris Ilias [:cilias] 2003-06-03 00:23:42 PDT
Should this bug remain as a 1.4 blocker?
Comment 57 Grant Weir 2003-06-03 15:23:50 PDT
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.
Comment 58 Chris Ilias [:cilias] 2003-06-03 23:06:47 PDT
> 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 59 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-06-04 13:34:48 PDT
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.
Comment 60 Pascal Chevrel:pascalc 2003-06-04 14:01:50 PDT
*** Bug 208308 has been marked as a duplicate of this bug. ***
Comment 61 Ninoschka Baca 2003-06-04 17:06:44 PDT
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.
Comment 62 Mike Kowalski 2003-06-10 02:03:09 PDT
*** Bug 203037 has been marked as a duplicate of this bug. ***
Comment 63 Vedran Miletic 2003-06-11 01:59:01 PDT
Bug 190193 also caused the bug 195598 - was that bug fixed on 1.4 branch too
when this one was fixed?
Comment 64 Mike Coppins 2003-06-18 11:34:59 PDT
Using 1.4 RC2 / win32, I haven't seen any repainting problems so far.
Comment 65 Mike Cowperthwaite 2003-06-18 11:46:26 PDT
The similar problem described in bug 167468 (dupe'd by bug 183701) has not been 
fixed in RC2.
Comment 66 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2003-07-10 18:12:07 PDT
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.
Comment 67 Mike Coppins 2003-07-11 03:05:49 PDT
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 Vedran Miletic 2003-07-11 04:50:18 PDT
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.
Comment 69 Karsten Düsterloh 2003-07-11 07:06:19 PDT
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 Mike Kaply [:mkaply] 2003-07-18 13:01:24 PDT
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?
Comment 71 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-07-21 10:09:37 PDT
We either need a way to reproduce this on Linux, or a developer with a Windows
build to do some debugging...
Comment 72 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-07-21 11:53:57 PDT
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 Mike Kaply [:mkaply] 2003-07-21 15:00:09 PDT
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 :)
Comment 74 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-07-21 15:19:32 PDT
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 Mike Kaply [:mkaply] 2003-07-21 20:10:52 PDT
yes. Overlaying causes a repaint, as does any selection.
Comment 76 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-07-21 20:38:28 PDT
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 Asa Dotzler [:asa] 2003-07-27 18:48:52 PDT
mozilla1.5a released. unsetting blocking request.
Comment 78 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-07-29 19:21:02 PDT
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.
Comment 79 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-08-17 21:56:46 PDT
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.))
Comment 80 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-08-17 21:58:42 PDT
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.
Comment 81 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-08-17 22:01:54 PDT
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 82 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-08-18 10:31:12 PDT
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.
Comment 83 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-08-18 10:31:28 PDT
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.
Comment 84 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-08-18 12:59:00 PDT
Fix checked in.
Comment 85 Mike Cowperthwaite 2003-08-19 10:20:10 PDT
*** Bug 214988 has been marked as a duplicate of this bug. ***
Comment 86 Mike Cowperthwaite 2003-08-19 10:22:12 PDT
(sorry, erroneous dupe)
Comment 87 Vedran Miletic 2003-09-01 08:07:01 PDT
v
Comment 88 Boris Zbarsky [:bz] (still a bit busy) 2003-09-29 23:34:47 PDT
This seems to have caused bug 220698
Comment 89 Boris Zbarsky [:bz] (still a bit busy) 2003-11-03 15:40:54 PST
And bug 224607 

Note You need to log in before you can comment on or make changes to this bug.