If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Design and Implementation of nsMsgWindow tracking bug

RESOLVED WORKSFORME

Status

MailNews Core
Backend
P3
normal
RESOLVED WORKSFORME
18 years ago
9 years ago

People

(Reporter: scottputterman, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
I figured I'd file a bug on this since it'll be taking up some time.  Basically,
we need a way to pass window specific information from the frontend to the
backend.  This work will include:

1.  Creating an nsMsgWindow object that will be created in js and passed
throughout the backend.  It will contain the current open folder, the
transaction manager, thread view data, message view data, folder view data, the
msgStatusFeedback, and the urlLoadGroup for the window.  Of course other things
can be added.  It will also have the ability to perform actions like Stop().

2.  Break up nsMessenger.  We agreed we could move everything in this class to
either the nsMsgWindow object, js, or nsMsgMailSession.

3.  Create a thread view interface and object and use it instead of the current
MessageView object which should instead be used for data relating to the message
view itself.

4.  Create an array of nsMsgWindows that can be put in the msg mail session so
that they can be iterated over throughout the code.  Applications of this
include the ability to determine if a folder is currently open in any window.

5.  Implement the ability to remember the selected folder and store it in the
nsMsgWindow

6.  change the name of nsMsgMailSession to something that is more descriptive of
what it does.  We might also break this up into other services.  That's unclear
at the moment.
(Reporter)

Updated

18 years ago
Summary: Design and Implentation of nsMsgWindow tracking bug → Design and Implementation of nsMsgWindow tracking bug

Comment 1

18 years ago
Scott, I haven't had time yet to read the email thread that started this bug
report but I wanted to see if you could work on the nsMsgWindow object
before doing some of the other things like 4-6....

Even if the class is a shell and not being passed around anywhere, I can still

go ahead and add my uri content handler interface support on this class without
being blocked on you needing to do the rest? Does that make sense?

Comment 2

18 years ago
It's already checked in.

Comment 3

18 years ago
ok, I've made the account manager a service... this means we can now get rid of
the GetAccountManager() API in nsIMsgMailSession once we've fixed all the calls.

While we're doing that, we should get rid of GetCurrentIdentity() and
GetCurrentServer() and make the callers of these functions go to the account
manager an call GetAllIdentities and GetAllServers and then just take the first
element of the array that is returned.

When that is complete, we will have successfully broken the account manager from
MsgMailSession...which means nsMsgMailSession is almost entirely a
FolderListener manager...
(Reporter)

Comment 4

18 years ago
great.  I just added to it though :)  I'm adding an array of nsIMsgWindows for
step 4.
(Reporter)

Comment 5

18 years ago
I've checked in all of the parts that should allow everyone to get their work
done.  The only things not done yet are the breaking up of nsMessenger, the
renaming of MessageView to ThreadView and the renaming of nsMsgMailSession.
But, we now have an nsIMsgWindow that gets created in js and stored in the
datasource, we add the nsIMsgWindow to an array accessible through
nsIMsgMailSession, and we store the open folder for that window.

Updated

18 years ago
Target Milestone: M11

Comment 6

18 years ago
M11
(Reporter)

Updated

18 years ago
Target Milestone: M11 → M12
(Reporter)

Comment 7

18 years ago
The more crucial parts of this bug have been implemented(Steps 1,4, and 5).  The
others can wait since I don't think they are holding anyone up.  I will move
this to M12 for the moment.
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M12 → M16
(Reporter)

Comment 8

18 years ago
Moving to M20. Some of this is being done with my work on rewriting the UI but
this is all architecture which should eventually be done but not necessarily by
the beta2 time period.
Target Milestone: M16 → M20

Comment 9

18 years ago
should this be nsbeta2?
(Reporter)

Comment 10

18 years ago
most of this is done and I don't think the rest needs to be done for this
product.  Marking future.
Target Milestone: M20 → Future

Comment 11

17 years ago
"..I don't think the rest needs to be done for this
product.  Marking future."

Future == WONTFIX?
(Reporter)

Comment 12

16 years ago
reassigning to sspitzer.  But, I'm not sure how much of this is left or if any
of it's relevant after the last couple of years worth of work so feel free to
mark Invalid or Worksforme.
Assignee: putterman → sspitzer
Status: ASSIGNED → NEW

Updated

15 years ago
QA Contact: lchiang → nobody

Comment 13

14 years ago
this was fixed a long time ago.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.