127707 - Deleting news account doesn't remove newsgroups/eventually crash [@ nsMsgKeySet::IsMember]

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[marina]

**** observed with 2002-02-25 build ***
Steps to reproduce:
- go to the Account manager (Edit|Mail/Newsgroup settings)
- select a news account;
- remove it, ok the prompt whether you want to remove it;
- now create a new news account;
//note: when the account is in the left pane you see the old newsgroups under
the tree, would you select one of them you would be asked whether you want to
subscribe,trying to subscribe loops indefinetely on Mac and crashes on WinNT

Comment 1

[marina]

i crash when i am trying to select a message that shows as if you are subscribed
, here is a stack ( btw; i can reproduce the crash on Mac as well):
Stack Trace
nsMsgKeySet::IsMember
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgKeySet.cpp, line 632]
nsNewsDatabase::IsRead
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsNewsDatabase.cpp, line 214]
nsNewsDatabase::IsHeaderRead
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsNewsDatabase.cpp, line 228]
nsMsgDatabase::GetStatusFlags
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp, line 1598]
nsMsgHdr::GetFlags
[d:\builds\seamonkey\mozilla\mailnews\db\msgdb\src\nsMsgHdr.cpp, line 208]
nsMsgDBFolder::HasMsgOffline
[d:\builds\seamonkey\mozilla\mailnews\base\util\nsMsgDBFolder.cpp, line 922]
nsNntpService::DisplayMessage
[d:\builds\seamonkey\mozilla\mailnews\news\src\nsNntpService.cpp, line 295]
nsMessenger::OpenURL
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMessenger.cpp, line 587]
nsMsgDBView::LoadMessageByMsgKey
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 891]
nsMsgDBView::SelectionChanged
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgDBView.cpp, line 930]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2000]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2803]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 850]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3417]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1821]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3383]
nsOutlinerSelection::FireOnSelectHandler
[d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerSelection.cpp,
line 738]
nsOutlinerSelection::Select
[d:\builds\seamonkey\mozilla\layout\xul\base\src\outliner\src\nsOutlinerSelection.cpp,
line 369]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2000]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 834]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2803]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 850]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 925]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3417]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsXBLPrototypeHandler::ExecuteHandler
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLPrototypeHandler.cpp, line 442]
DoMouse [d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLDragHandler.cpp, line 115]
nsXBLMouseHandler::MouseDown
[d:\builds\seamonkey\mozilla\content\xbl\src\nsXBLMouseHandler.cpp, line 124]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1307]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3383]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6010]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5928]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2010]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 301]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1849]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 858]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 875]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4579]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4829]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3504]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1120]
USER32.dll + 0x1820 (0x77e71820)
0x015f0053 

Comment 2

[Ninoschka Baca]

Trunk build 2002-03-01: Mac OS/X
I reproduced the crash.

- I had many mail accounts so collapsed all of them so there was plenty of room
for the news account and its news groups (alt.surfing)to display.
- removed the news account and without closing Account Settings
- added the same news account back in
- Closed Account Settings

Actual Results: The newsgroups that I had been subscribed to earlier
(alt.surfing) was there. I was able to subscribe to a different newsgroup but
when I select alt.surfing then it crashed immediately.

Note: I wasn't able to reproduce this earlier because my mail accounts were
expanded so the news account was off screen at the bottom. Once I maximized the
area for the news account then I saw the problems.

I will try the 2002-03-07 build once it installs.

Marking nsbeta1 since it's crashing.

Comment 3

[Ninoschka Baca]

Trunk build 2002-03-07: Mac 10.1.3
Reproduced using Marina's steps so that after the account is readded the old
newsgroup appears (alt.surfing), select the newsgroup and it asks if you want to
subscribe, ok, then select a message in the thread pane and it crashes.

Comment 4

[Michael Buckland]

Discussed at Mail News bug mtg with Mktng, Eng, PjM.  Decided to plus this bug.
 Also to mark bug 123038 a dupe of this bug, which has move info in it.

Comment 5

[Michael Buckland]

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

Comment 6

[varada]

I tried the steps that both marina and ninoschka had mentioned with my build as
well as a release build.
The chosen newsgroup( I stuck to alt.surfing:-) ) did show up with the message.
When I clicked on the newsgroup there was a dialog box that asked whether I
wanted to subscribe to the newsgroup. Irregardless of what I chose( CANCEL or
OK) and then clicked on a message it didnt crash. Though in the case of cancel -
there was this appearance of something going on (mouse turning into hourglass)
but that didnt prevent me from going to other accounts or reading other mail,
news or otherwise.

Suggest we either find another way of reproducing the crash or we can probably
minus this one or leave it as a major bug because we dont want previously
subscribed newsgroups to show up after deleting the news server.

Comment 7

[varada]

Taking bugs from bhuvan.

Comment 8

[scottputterman]

I couldn't reproduce this bug either using the steps.  But, the stack for this
crash is still showing up in talkback as of 3/22.

Comment 9

[marina]

i am able to reproduce this bug (meaning crash) with 03-26 build with a
different profile. The problem that when we remove an account (news in this
case) and then add it again without exiting the application shows newsgroups
that you were previosly subscribed to. We have to fix this problem but to crash
with 03-26 build all you have to do is to "OK" the prompt whether you want to
subscribe to the following newsgroups.

Comment 10

[[e-mail] (gone - use [e-mail] instead)]

Same here, 2002-03-26-03, Win2k using secnews.netscape.com.

Comment 11

[marina]

it might be win2k problem ( i am as Stephen on win2k) but i doubt that...

Comment 12

[Ninoschka Baca]

I reproduced the crash on my WinMe system.
Incident# 4530315.

Comment 13

[Michael Buckland]

Discussed in Mail News bug meeting. Decided to [ADT3] this bug.

Comment 14

[Ninoschka Baca]

Trunk build 2002-03-27: WinMe
More incident numbers (4573692, 4573306)  

Comment 15

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 16

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 17

[scottputterman]

changing back.  If we had a fix for this we'd take it.

Comment 18

[David :Bienvenu]

I can reproduce this - not sure why Varada couldn't...I'll fix it. The problem
is almost certainly that m_keySet is not valid anymore. I wonder if we're not
closing down the nntp connections when we remove the server and running into a
problem using a cached connection...

Comment 19

[David :Bienvenu]

updating status whiteboard. The problem is that there's a circular reference
between the nntp protocol object and the nntp incoming server (the protocol
object points to the server, and the server has a list of protocol objects). We
can either use a weak reference in the protocol object (but that would involve
changing a lot of code), or we can break the link when removing the account.

Comment 20

[David :Bienvenu]

Attachment: proposed fix

fix is basically to shutdown the folders on the removed account - I needed to
move up the forgetting of the passwords because it needs the server to be still
set on the folder (shutdown clears the server).

Comment 21

[David :Bienvenu]

Navin, can I get an r=? thx.

Comment 22

[(not reading, please use [e-mail] instead)]

Comment on attachment 80806 [details] [diff] [review]
proposed fix

sr=sspitzer

thanks for fixing this, david.

Comment 23

[Navin Gupta]

Comment on attachment 80806 [details] [diff] [review]
proposed fix

we do something similar in 
hashLogoutOfServer, probably 
we could add a helper method

+    server->CloseCachedConnections();
+    // need to forget pasword before we shutdown folders.
+    rv = server->ForgetPassword();
+    NS_ASSERTION(NS_SUCCEEDED(rv), "failed to remove the password associated
with server");
+

Also if we call shutdown(PR_TRUE); you can
remove that ForceDBClosed() call just  
below it because folder's
db will already have been
nulled out.

Comment 24

[David :Bienvenu]

ForceDBClosed actually forces the db closed; nulling out the db is no guarantee
that the db will get closed, so that comment is wrong.

I'm not inclined to add yet another interface to nsIMsgIncomingServer for these
two lines of code...

Comment 25

[Navin Gupta]

folder->ForceDBClosed() will check for mDatabase (so that it can do
mDatabase->ForceClosed()) which will be nulled out by
folder->Shutdown(PR_TRUE)

I was suggesting adding a helper function to nsMsgAccountManager.h

nsresult
nsMsgAccountManager::LogoutOfServer(nsIMsgIncomingServer *aServer)
{
+    server->CloseCachedConnections();
+    // need to forget pasword before we shutdown folders.
+    rv = server->ForgetPassword();
+    NS_ASSERTION(NS_SUCCEEDED(rv), "failed to remove the password associated
with server");
+
}

Comment 26

[David :Bienvenu]

so, what you meant to say is that the force closed should be called before the
shutdown call? Good catch, that's true; I'll fix that.

Comment 27

[David :Bienvenu]

Attachment: patch addressing Navin's comments

Comment 28

[Navin Gupta]

Comment on attachment 80869 [details] [diff] [review]
patch addressing Navin's comments

r=naving

Comment 29

[(not reading, please use [e-mail] instead)]

Comment on attachment 80869 [details] [diff] [review]
patch addressing Navin's comments

sr=sspitzer

Comment 30

[scottputterman]

adding adt1.0.0 nomination.

Comment 31

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for checkin to 1.0. Pls check this in today, after
you receive Drivers approval. Then, add the fixed1.0.0 keyword.

Comment 32

[David :Bienvenu]

fixed on trunk, waiting for driver approval.

Comment 33

[Asa Dotzler [:asa]]

Comment on attachment 80869 [details] [diff] [review]
patch addressing Navin's comments

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 34

[David :Bienvenu]

fixed on branch

Comment 35

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 36

[[e-mail] (gone - use [e-mail] instead)]

I'm thinking that I'll probably have to spin off a separate bug for the problem
I'll describe below:

1) Have a news server selected (choose one with a subscribed newsgroup), bring
up Account Manager.
2) Remove the account, then re-add it.
3) Once you've re-added it, the same group re-appears and once you click on it,
no messages are populated (it's like our cache is empty, but happy).

Could this be a result of http://bugzilla.mozilla.org/show_bug.cgi?id=94967#c1

If so, I'll just file the above scenario.  I don't crash on builds 2002-04-26 on:

Mac OS X 10.1.4
Windows 2000
Mandrake 8.1

But, I had a very similar but slightly different stack that I'll investigate in
this area (it starts with nsMsgKeySet::Output(), then
nsMsgNewsFolder::UpdateSummaryFromNNTPInfo()).

David, that crash stack is shown in
http://climate.netscape.com/reports/SingleIncidentInfo.cfm?dynamicBBID=5657942

Verified for the BRANCH, trunk is next. 

Comment 37

[[e-mail] (gone - use [e-mail] instead)]

Okay, this doesn't appear to be fixed, either on the trunk or the branch.

Although I'm not seeing the nsMsgKeySet::IsMember stack, others do:
5803791  2002043010   MozillaTrunk   Windows NT 5.0 build 2195   2002-04-30
23:49:54   nsMsgKeySet::IsMember 7e853fff   2038   3640   google.com

I *do* see nsMsgKeySet::Output() (doing the same steps), here's my full stack:

Stack Signature nsMsgKeySet::Output 65781b7b
Email Address [e-mail]
Product ID NetscapeXXX
Build ID 2002050108
Trigger Time 2002-05-01 10:43:10
Platform Win32
Operating System Windows NT 5.0 build 2195
Module msgbsutl.dll
URL visited http://bugzilla.mozilla.org/show_bug.cgi?id=127707
User Comments Crashed trying to reproduce bug 127707
http://bugzilla.mozilla.org/show_bug.cgi?id=127707
Trigger Reason Access violation
Source File Name d:uildsseamonkeymozillamailnewsaseutil
sMsgKeySet.cpp
Trigger Line No. 315
Stack Trace
nsMsgKeySet::Output
[d:uildsseamonkeymozillamailnewsaseutil
sMsgKeySet.cpp, line 315]
nsMsgNewsFolder::UpdateSummaryFromNNTPInfo
[d:uildsseamonkeymozillamailnews
ewssrc
sNewsFolder.cpp, line 797]
nsNntpIncomingServer::DisplaySubscribedGroup
[d:uildsseamonkeymozillamailnews
ewssrc
sNntpIncomingServer.cpp, line 705]
nsNNTPProtocol::DisplayNewsRCResponse
[d:uildsseamonkeymozillamailnews
ewssrc
sNNTPProtocol.cpp, line 4172]
nsNNTPProtocol::ProcessProtocolState
[d:uildsseamonkeymozillamailnews
ewssrc
sNNTPProtocol.cpp, line 5266]
nsMsgProtocol::OnDataAvailable
[d:uildsseamonkeymozillamailnewsaseutil
sMsgProtocol.cpp, line 306]
nsOnDataAvailableEvent::HandleEvent
[d:uildsseamonkeymozilla
etwerkasesrc
sStreamListenerProxy.cpp, line 202]
PL_HandleEvent [d:uildsseamonkeymozillaxpcom	hreadsplevent.c, line 597]
PL_ProcessPendingEvents [d:uildsseamonkeymozillaxpcom	hreadsplevent.c,
line 530]
_md_EventReceiverProc [d:uildsseamonkeymozillaxpcom	hreadsplevent.c, line
1078]
nsAppShellService::Run
[d:uildsseamonkeymozillaxpfeappshellsrc
sAppShellService.cpp, line 309]
main1 [d:uildsseamonkeymozillaxpfeootstrap
sAppRunner.cpp, line 1434]
main [d:uildsseamonkeymozillaxpfeootstrap
sAppRunner.cpp, line 1769]
WinMain [d:uildsseamonkeymozillaxpfeootstrap
sAppRunner.cpp, line 1787]
WinMainCRTStartup()
KERNEL32.DLL + 0xd326 (0x77e8d326)

Re-opening. Removing verified1.0.0, adding the new related stack to the summary
(nsMsgKeySet::Output)

Comment 38

[David :Bienvenu]

Stephen, I think we need new reproducible steps to recreate this bug. I believe
the steps we used to have work fine now (though you can verify that if you
like...) and it follows that there is some other scenario that can lead to this
crash.

Comment 39

[scottputterman]

removing the adt1.0.0+.  Let's try to get this for rtm.

Comment 40

[marina]

Stephen, i used the steps of my initial bug report to reproduce the problem and
i wasn't able to with 2002-05-01 trunk build. It seems to be fixed ( the news
account got removed). What are the steps you used to get a crash?

Comment 41

[[e-mail] (gone - use [e-mail] instead)]

Okay, I've failed to reproduce the nsMsgKeySet::IsMember crash, and lately I'm
having problems (on a new profile) reproducing the nsMsgKetSet::Output crash - I
need to whittle away the steps to reproduce before I file a new bug.

Although, someone has still crashed in nsMsgKeySet::IsMember with the
2002-04-30-10  Windows 2000 build - no steps to reproduce, either.

I'm not sure what to do about this bug - sorry for the snafu, but for 4 times
straight the crash in nsMsgKeySet::Output was reproducible 100%, using the same
steps:

1.  Add a news server, subscribe to a group.
2.  Go to the Account Manager, remove the account.
3.  In the same session, re-add the account.
4.  It'll populate that group, click on it and you'll be prompted to confirm
subscription to the account, which you say "OK" to.
5.  This is where I crashed in the global Output() method.

Since I can no longer reproduce either crash, I'll remove the output stack from
the bug, and leave it open for us to decide what to do about the single crash in
nsMsgKeySet::IsMember on the 30th...

Also, I see that re-adding the server and having it populate the newsgroups that
you had before, is probably a result of
http://bugzilla.mozilla.org/show_bug.cgi?id=94967#c1

Re-adding verified1.0.0, for the time being, since like I said I can't reproduce
using Marina's steps...  Sorry.

Comment 42

[David :Bienvenu]

Stephen, I can't tell if were/are using a branch build or a trunk build. Also,
if when you add the server back, you're getting all the old subscribed groups
back, then that's the cause of the crash. Those subscribed groups should have
been cleared out when we unload the server...

Comment 43

[[e-mail] (gone - use [e-mail] instead)]

I was using today's commercial Mozilla 1.0 branch build - the person who crashed
on 4-30 with Windows 2000 in nsMsgKeySet::IsMember was using MozillaTrunk.

Yes, I'm still getting my previously subscribed newsgroups returned on addition
of my previously removed account - I thought this might be a separate bug -
since the summary state 'Deleting news account doesn't remove newsgroups' - it
has no mention of what happens when we add it back.

Your fix was to clear the news cache in general?  

Comment 44

[marina]

in today's branch build i see same as Stephen does: the first impression is that
the news account(news.mcom.com is removed after you select the Remove option on
the Account wizard) because it doesn't show up in the account central, then if
you add this account again it'll show up with all prevviously existing
newsgroups, they have no articles though and do not crash.

Comment 45

[David :Bienvenu]

for the branch, it turns out this relies on getting another fix in, adding
mSubFolders->Clear() to nsMsgFolder::Shutdown. I thought that was going to get
checked in but it doesn't seem to have been. I'll go look for the bug #.

Comment 46

[David :Bienvenu]

the fix in bug 138217 is required to fix this on the branch. I'll submit the
patch in a minute.

Comment 47

[David :Bienvenu]

Attachment: patch required from trunk

this last patch is also required.

Comment 48

[scottputterman]

removing verified1.0.0 and renominating.

Comment 49

[Jaime Rodriguez, Jr.]

Removing adt1.0.0, as this has been reopened.

Comment 50

[David :Bienvenu]

this is fixed on the trunk - deleting the account and re-adding it doesn't
result in the newsgroups reappearing, right, Stephen? There might be other
instances of that stack trace crash, but case of it is fixed on the trunk.

Comment 51

[scottputterman]

adding the adt1.0.0 back.  The new patch was already checked in.  We just need
this on the branch now.

Comment 52

[[e-mail] (gone - use [e-mail] instead)]

David, correct - deleting a news account via the Account Manager and readding it
in the same session does not repopulate the server with newsgroups you had
subscribed to before.  There are a few other stacks in nsMsgKeySet::, but I
haven't nailed down the steps to see those global methods crash.

Comment 53

[scottputterman]

adding adt1.0.0+.  Please get drivers approval and then check into the 1.0 branch.

Comment 54

[[e-mail] (gone - use [e-mail] instead)]

Verified FIXED on the trunk with builds:

Windows 2000 - latest trunk (self-built)
Redhat 7.3 - 2002-05-25-07
Mac OS X 10.1.14 - 2002-05-24-08

David/Putterman/ADT - this is fine on the trunk.

Comment 55

[scottputterman]

changing to adt1.0.1+ for checkin to the 1.0 branch.  Please get drivers
approval before checking in.

Comment 56

[Judson Valeski]

please checkin to the 1.0.1 branch ASAP. once there please remove the
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword.

Comment 57

[David :Bienvenu]

fixed on 1.01 branch

Comment 58

[[e-mail] (gone - use [e-mail] instead)]

This fix is working fine now on all 2002-05-31 Mozilla1.0.1 Branch builds
(commercial):

Mac OS X 10.1.4, Mac OS 9.2.2, Windows 2000, RedHat Linux 7.3

Verified FIXED on branch, replacing fixed1.0.1 with verified1.0.1.