Closed Bug 114952 Opened 23 years ago Closed 22 years ago

Labels: not available in standalone msg window, Message & context menu items disabled.

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: laurel, Assigned: ssu0262)

References

Details

(Whiteboard: [ADT2 RTM],custrtm-)

Attachments

(1 file, 1 obsolete file)

Using dec12 commercial trunk build

Label command is disabled in the standalone window via Message menu or context
menu.  Should be available for use in standalone message window.
QA Contact: esther → laurel
Keywords: nsbeta1
Status: NEW → ASSIGNED
Keywords: nsbeta1nsbeta1+
Priority: -- → P3
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
*** Bug 129678 has been marked as a duplicate of this bug. ***
*** Bug 146026 has been marked as a duplicate of this bug. ***
renominating for rtm since this came up in the usability study today and was a
source of much angst for the subject. It makes labels useless for our users that
work out of the stand alone message window mode. 
Keywords: nsbeta1-nsbeta1
Well, even if it's enabled, it's still not too useful?  I think we need some
kind of indicator in the standalone window
I dunno what anyone else uses it for, but I want to identify or categorize
selected messages -- mostly so I know what to keep.  I am most able to tell what
is useful while I'm reading the message.  

I don't know what <putterman@netscape.com> means about "too useful."  It would
be *nice* if the label (and, maybe, the flag and priority) appeared in the
header info of the standalone window.  But it's _important_ to be able to set
the label attributes, just as I can with the flag.
Discussed in mail news bug meeting. Decided to plus this bug.
Keywords: nsbeta1nsbeta1+
Whiteboard: [ADT2 RTM]
Target Milestone: --- → mozilla1.0.1
Whiteboard: [ADT2 RTM] → [ADT2 RTM],custrtm-
Attached patch patch v1.0 (obsolete) — Splinter Review
here's the first try at a patch.  I still need to do more testing because of
the change to GetLoadedMsgFolder() in messageWindow.js.
Attached patch patch v1.1Splinter Review
better patch. seeking reviews now.
Attachment #86823 - Attachment is obsolete: true
By the time this is checked in and actual verification is needed, could someone
expound on what is entailed in the fix/implementation and perhaps even a spec
update? Thanks. 
Currently, the stand alone message window's menu and context menu show the
labels menu items as disabled.  To change this so that it'll be enabled, the fix
just added labels command handlers to the stand alone's command handler functions.

The spec on the standalone message window does not mention labels at all:
  http://www.mozilla.org/mailnews/specs/threepane/MailMenus.html#standalone

You can take a look at today's build for both the regular menu and context menu
in the standalone message window to see where the labels menu item is at.  The
only difference between today's build and this patch is that today's build will
simply have the labels menu items disabled.
I forgot to mention that currently, there's also no spec on how to indicate to
the user (in the standalone message window) which label (if any) the message is
set to.  We'll probably need a seperate bug for this.

so when this bug gets fixed, the user will be able to set a label in the
standalone message window, but not know what it's set to afterwards by just
looking at the message window.
So, it'll be like flag is, in that it will just update the 3-pane?
well.... that's the other problem.  It doesn't update the 3pane immediately
correctly.  you have to click on the threadpane before it repaints properly, or
move a window ontop then off of it.  this is a different bug though.
but if you get to the labels menu again in the standalone message window, it'll
be marked correctly as to which label the message has been set to.
Content menus for the standalone msg window should be the same as for a message 
being displayed in the Message Pane. Context menu spec is here:
http://www.mozilla.org/mailnews/specs/threepane/MailMenus.html#Context

>there's also no spec on how to indicate to the user (in the standalone message 
>window) which label (if any) the message is set to.  We'll probably need a 
>seperate bug for this.

Yeah. We'll have to decide if we want some sort of indicator in an open msg. Do 
we think people will find an indicator of labels in open msgs useful or will 
they primarily be using labels to sort and organize msgs in the 3 pane? 
The portion about adding the labels command handlers seem fine. The function
GetSelectedIndices(dbView) doesnt seem to be called anywhere in the patch or are
you referring to it someplace else and does it need to be changed here?
jglick: I definitely would find it useful.  In general, I think it's a good idea
to let the user see what they just did; some kind of visual feedback.

varada: yes, it's being called in mailWindowOverlay.js from InitMessageLable().
>jglick: I definitely would find it useful.  In general, I think it's a good 
>idea to let the user see what they just did; some kind of visual feedback.

If you like, you can file a bug against me for this to track it.
jglick, bug 150560 filed for label visual feedback in the standalone message window.
Comment on attachment 86844 [details] [diff] [review]
patch v1.1

I guess the duplication of functions with msgmail3panewindow.js is because they
are not overlayed together
r=varada
Attachment #86844 - Flags: review+
Comment on attachment 86844 [details] [diff] [review]
patch v1.1

sr=bienvenu
Attachment #86844 - Flags: superreview+
Keywords: mozilla1.0.1
Keywords: adt1.0.1
patch checked in to trunk only.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: mozilla1.0.1
Resolution: --- → FIXED
adding adt1.0.1+.  Please get drivers approval before checking in.
Marking verified on trunk.
OK using june12 commercial trunk: win98, mac OS 10.1, linux rh6.2.
Logged bug 151266 about 3-pane update issue.
Status: RESOLVED → VERIFIED
Comment on attachment 86844 [details] [diff] [review]
patch v1.1

Please land this on the 1.0.1 branch.  Once there, remove the
"mozilla1.0.1+" keyword, and add the "fixed1.0.1"
Attachment #86844 - Flags: approval+
patch checked in to the branch.
Keywords: mozilla1.0.1fixed1.0.1
OK in commercial branch builds:
June18 branch linux rh6.2
June19 branch win98, mac OS 10.1
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: